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This publication presents the design considerations associated with 
installing and operating Information Management System/Virtual Storage 
(IMS/VS).- It presents IMS/VS concepts, and the facilities available for 
designing IMS/VS Data Base (DB) and Data Base/Data Communication [DB/DC) 
systems. 


This publication provides data base administrators, system designers, 
system programmers, and application programmers with the information 
they require to design an IMS/VS system and to design the applications 
which operate under IMS/VS. 


Prerequisite to this publication is the IMS/VS General Information 
Manual, GH20-1260. In addition to information in the IMS/VS General 


Information Manual, the reader is expected to have a knowledge of 


Operating System/Virtual Storage (OS/VS) and OS/VS access methods. The 
chapters in this publication are; 


1. “Design, Installation, and Maintenance of the IMS/VS Data Base 
System" that addresses the factors to be considered when 
installing a DB systen. 


2. "Design and Control of the Data Base/Data Communication Systen' 
that addresses the factors to be considered when installing a 
DB/DC systen. 


3. “Application Program Design" that includes considerations for 
design of batch and telecommunication IMS/VS applications. 


4. “Data Base Design Considerations" that describes data base 
concepts, structures, and the options available for designing 
IMS/VS data bases. 


5. “Design Considerations for the Multiple Systems Coupling (MSC) 
Feature” that describes MSC and contains d2sign considerations 
for its use. 


6. "Design Considerations for the Fast Path Feature" that describes 
Fast Path and contains design considerations for its use. 


ZIMSZVS Installation Guide, SH20-9081 


This publication presents step-by-step details for the IMS/VS 
installation process. 


IMNSZVS System Programming Reference Manual, SH20-9027 
This manual provides system programming personnel with 
installation considerations and details for generation 


(definition) of an IMS/VS systen. 


This document is a reference manual for the application 
programmer. It provides information about the coding 
techniques necessary to implement a designed application 
under the IMS/VS systen. 
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INSZVS Utilities Reference Manual, SH20-9029 
This manual provides a description of the IMS/VS system 
utility programs. It describes how to execute these 
utilities under the operating systen. 


IMSZVS Operator's Reference Manual, SH20-9028 
This manual provides the master terminal, remote terminal, 
and system console operators with the information associated 
with operating IMS/VS once the system has been established in 


a user envircnment. 


IMS/VS Message Format Service User's Guide, SH20-9053 
This manual describes the use, definition, and implementation 
of the Message Format Service (MFS). 


INS/VS Advanced Function for Communications, SH20-9054 
This manual explains the IMS/VS support for advanced function 
communications systems. It addresses the areas that 
programmers or analysts involved in communicating with IMS/VS 


must be familiar with. 


This manual lists, explains, and suggests appropriate 
responses to the completion codes and messages produced by 
all the IBM-supplied components of the IMS/VS systen. 


MSZVS Failure Analysis Structure Tables (FAST) for Dump 
hRalysis, LY2Z0-8050 
This manual contains a simple, structured approach to 
defining IMS/VS programming failures. This manual is for 
both IMS/VS users and IBM programming support representatives 


who diagnose IMS/VS problems. 


IMS/VS Diagnostics Aids, LY20-8063 
This manual assists the IBM programming support 
representative and customer system programmers in using 
RETAIN/EWS for diagnosing IMS/VS programming failures. It 
provides a systematic approach both for searching RETAIN/EWS 
for IMS/VS failures and for constructing a set of keywords as 
entries into RETAIN/EWS. 


INSZVS Program Logic Manual, LY20-8069 
The IMS/VS Program Logic Manual provides high level logic 
analysis information to programming systems representatives 
responsible for the maintenance of the IBM Information 
Management System/Virtual Storage (IMS/VS). The format of 
this manual farallels the function/subfunction breakdown 


employed in the IMS/VS Diagnostics Aids, LY20- 8063. 
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SUMMARY OF AMENDMENTS 


VERSION 1, RELEASE 125 


NEW PROGRAMMING FACILITIES 


® Access to Fast Path and IMS/VS data bases is available from both 
Fast Path and IMS/VS application programs within the same 
transaction process. 


e A utility can be used for partial reorganization of HIDAM and HDAM 
data bases. 


PROGRAMMING ENHANCEMENTS 


e Extended security support can be used with RACF or a user-written 
exit routine to provide sign-on processing for user verification to 
determine whether or not a user is authorized to use a transaction 
code. Data base change tracking by specifics user is facilitated by 
log records containing user identification obtained from user 
verification. 


e Additional screen sizes and PF keys of the IBM 3270 Information 
Display System are supported by Message Format Service (MFS). 


e More flexible use of I/O resources is made in the allocation and 
deallocation of IMS/VS data bases and DC Monitor log data set [OS/VS 
MVS only). 


e The time required to restart an IMS/VS system is reduced. 
Enhancements include restarting from the disk log, online log 
termination, use of the dynamic log from shutdown for data base 
backout at restart, and automatic restart. 


NEW PROGRAMMING FEATURE 
A Data Base Surveyor utility is available as a separate feature. This 
utility scans the data base being analyzed and provides a report 


describing the physical organization and the location and size of free 
space. 


SPECIFICATION CHANGES 


BDGE 


=z 


e The minimum logical record length for primary/secondary data set 


T 
groups for HISAM data bases has been lowered. 
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DEDB Dasd Space Definition 
e An example of DEDB dasd space definition is included. 
e Sample minimum space calculations are provided. 


e Performance considerations are discussed. 


Delete/Replace Rules 
A clarification of the Delete rules for both logical parents and 
physical parents has been included. 


Nongraphic Message Data 

A section describing the IMS/VS sensitivity to specific characters 
when users attempt to send and receive nongraphic data in IMS/VS 
messages has been added. 


SERVICE CHANGES 


NEW PROGRAMMING FEATURE 


The Fast Path feature provides data base and data communication 
facilities for applications requiring high transaction rates but needing 
only simple data base structures. The Fast Path feature uses functions 
of the Data Communication feature and operates in existing 
t2lecommunication networks. 


Fast Path provides two new types of data bases that are accessed with 
standard DL/I calls and, optionally, with Fast Path DL/I calls. The 
feature includes a message-handling facility to expedite the processing 
of Fast Path messages. 


VERSION 1, RELEASE 1 
This publication has been revised to reflect technical and editorial 
changes made for Release 1.2. 


TECHNICAL CHANGES 


Multiple Systems Coupling Feature 

The Multiple Systems Coupling feature allows a user to define a 
configuration consisting of up to 255 interconnected IMS/VS systems 
running on any combination of OS/VS1i'and OS/VS2. Information on 
channel-to-channel communication with the Multiple Systems Coupling 
feature is for planning purposes only until IMS/VS support for this 
facility becomes available. 
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3279 Information Display Station 


With the addition of Synchronous Data Link Control, 3270s can now be 
attached on SDLC lines as well as BSC lines. 


3350 Direct Access Storage Device 


The 3350 may now be specified for data base and message queue data 
set residence. 


3770 Data Communication System 
The 3767 and 3770 are supported on an SDLC link through VTAM. Full 
IMS/VS functional capabilities are included. 


EDITORIAL CHANGES 


e The IMS/VS planning information about MSS (mass storage system), 
previously contained in DB/DC MSS Planning Information: IMS/VS, 


publication. The former MSS publication is now obsolete. 


e The information previously contained in Chapter 1 of this 
publication has been moved to the IMS/VS General Information Manual. 

e The information previously contained in Chapters 6 and 7 and 
Appendixes C and D of this publication has been moved to the IMS/VS 


e The information previously contained in Appendix B 
publication has been moved to the IMS/VS Applicati 


of this 
itis Lca n 
Reference Manual. 
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CHAPTER 1. DESIGN, INSTALLATION, AND MAINTENANCE OF THE IMS/VS DATA 


BASE SYSTEM 


This chapter addresses the factors to be considered by the user data 
processing organization in planning, scheduling and controlling the 
installation of the IMS/VS Data Base (DB) System. Three major time 
phases should be considered: 


e Pre-installation system design and configuration 
e Installation 
e System tuning and phased expansion 


For each of these phases, this chapter suggests the steps to be 
taken, referencing the tools provided by the data base management 
services of IMS/VS to facilitate the effort, and identifying those 
elements of the user installation which are involved or affected. 


DESCRIPTION OF FACILITIES 

The data base management services of IMS/VS are packaged as basic 
material in an orderable component called the Data Base (DB) systen. 
The DB system supports the implementation of multiple user-written batch 
processing applications in a common data base environment. 


The DB system provides the user with full IMS/VS facilities to: 
e Define, load, and reorganize data bases 


e Access a data base from application programs via a high-level 
language interface called DL/I 


e Support systems integrity via data base logging, checkpoint/restart, 
and data base recovery programs 


e Use system-provided exits to incorporate user extensions to IMS/VS 


e Migrate to a full IMS/VS DB/DC system in a shared terminal 
environment 


The major execution-time elements of the IMS/VS DB system are the 
DL/I (Data Language/I) interface and the data base logging program. 
DL/I interfaces between the problem program and the data bases the 
program wishes to access. The use of DL/I and its functions are 
Manual. The data base logging capability is one of the principal IMS/VS 
recovery features. It provides a log of all activity against a data 
base. The log enables a user to analyze and tune his system, and is the 
basic support for recovery, restart, and backout activity. The log is 
discussed later in this chapter. 


In addition, several utility programs which assist in creation and 
maintenance of the DB System are supplied. Included in this utility 
program set are: 

IMS/VS System Definition 


IMS/VS Data Base Description Generation 
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IMS/VS Program Specification Block Generation 

IMS/VS Application Control Blocks Creation and Maintenance 
IMS/VS Data Base Reorganization and Load 

IMS/VS Data Base Recovery 

IMS/VS Utility Control Facility 


System definition is described in the IMS/VS Ins 


other programs are described in the JIMS/VS Utili 
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SYSTEMS 
The DB system operates on an IBM System/370, using the services of 
OS/VS in its multiprogramming configurations OS/VS1 and OS/VS2. 


In the IMS/VS DB system, applications are scheduled for execution 
through the OS/VS job stream in a process called batch scheduling. The 
basic unit of work is assumed to be the operating system job step. The 
application itself can be either transaction-oriented or batch-oriented. 
A transaction-oriented program facilitates migration to a DB/DC 
environment. 


It is common system practice to implement the full DB/DC capabilities 
in a phased manner by installing a batch DB system first. Once an 
initial program/data base cluster has been designed and installed, users 
can see the step-wise expansion leading to a comprehensive on-line 
installation. 


Figure {-1 shows the relationship of OS/VS, the IMS/VS DB system, and 
an application program at execution time. The program and the DB systen 
are contained in a single batch-processing problem program address space 
(region, memory). A second application program can occupy a second 
address space, with a replica of the DL/I and data base logging 
functions, accessing a separate data base and writing a second log tape. 
Two or more IMS/VS batch systems can run concurrently in separate 
address spaces, if they do not access the same data bases. Most of the 
IMS/VS DB system is composed of reenterable code. 


The user's application program operates as an OS/VS problem progran. 
As illustrated in Figure 1-1, the application program has two basic 
interfaces. These are: 


1. Transaction Input and Response Output 
2. Data Base Input/Output Operations 


Although this is a batch processing environment, the concept of 
transaction processing is advocated, because it can be carried over to 
the IMS/VS message processing environment. Typically, transaction input 
and response output are performed with OS/VS data management. Within 
the application program, file descriptions and read/write statements are 
in COBOL, PL/I, or Assembler Language syntax. Alternatively, the user 
of IMS/VS can build an interface for transaction input and response 
output similar to the data base input/output interface described below. 
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Figure 1-1. IMS/VS Data Base System Environment 


All data base operations are initiated by the application program 
interface with DL/I. This interface consists of execution of a CALL 
statement from the application program. Parameters in this CALL 
statement provide the information necessary to perform a data base 
Operation On a specific data element or seqment in a specific data base. 
An application program can interface with one or more DL/I data bases. 
In addition, standard OS/VS data management can be used for any purpose 
in the application program. 


The arguments in the CALL statement issued by an application program 
allow DL/I to determine which data base is to be used and which data 
segment in the data base is to be retrieved, inserted, replaced, or 
deleted. From this information DL/I performs a VSAM, SAM, ISAM, or OSAM 
input/output operation. If the desired data segment already exists 
within the data base main storage buffers, no input/output operation is 
required. 


When the data base operation consists of data segment insert, 
replace, or delete, a record of the data base modification is written on 
an IMS/VS log for the batch processing address space. The content and 
format of logged information are described in a subsequent section of 
this chapter. 
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One significant concept of the data base input/output interface is 
that the format and content of all information used to establish the 
interface are symbolic. None of this information is dependent upon a 
specific data management access method or organization. 2 


Before the DB system can be used for batch data base processing, it 
must be tailored to the user's data processing environment. This 
process of system tailoring is called system definition. The details of 


For IMS/VS, the system definition function is similar, in concept, to 
OS/VS system generation. 


OS/VS OPTION CONSIDERATIONS 


The DB system operates under OS/VS1 or OS/VS2. Very little 
difference is experienced by the IMS/VS user, whether VS1 or VS2 is 
used. The primary differences are attributable to the OS/VS option 
characteristics. Chapter 2 of this manual describes the considerations 
for operation under VS1 or VS2. These are primarily concerned with main 
storage management and reliability/serviceability. The effects of VS1 
versus VS2 are considerably greater with the IMS/VS DB/DC systen. 


Only one OS/VS option defined during OS/VS system generation is a 
requirement for the DB system. This is user SVC inclusion. 


Other OS/VS options or features which are desirable, but not 
required, for IMS/VS are VSAM access method, ISAM access method, COBOL, 
and PL/I Optimizing Compiler. 


The ASSEMBLER, an IMS/VS requirement, is automatically incorporated Zo 
in OS/VS. Alternatively, the Assembler H program product may be used. 


IMS/VS SYSTEM DEFINITION 


During and after system definition and before DB system execution, 
several IMS/VS library data sets must be defined. These include control 
block libraries, load module libraries, and a procedure library. The 


in this chapter are: 


IMSVS.RESLIB the IMS/VS system load module library 


IMSVS.PGMLIB ~ the user's application program library 


IMSVS.DBDLIB - the IMS/VS control block library containing data base 
descriptions (DBD). Each member describes the 
logical structure of data and its physical storage in 
a data base. 


IMSVS.PSBLIB - the IMS/VS control library containing application 
program specification blocks (PSB). Each member 
contains a description of how its associated 
application program uses one or more data bases. 


IMSVS.ACBLIB - the IMS/VS library which contains control blocks 
required for a specific application program. This is 


a combination of the DBDs and PSBs in an internal ' 
format required by DL/I for data base systen ) 
execution. 
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IMSVS.PROCLIB - the IMS/VS procedure library containing IBN-supplied 
procedures. 


IMSVS.MACLIB - the IMS/VS macro instruction library containing at 
least DBD generation and PSB generation macro 
instructions. 


Special Access Method -- OSAM 


The Overflow Sequential Access Method (OSAM) is a special data 
management access method supplied with IMS/VS. It is used with some of 
the IMS/VS data base organizations. The functions which OSAM performs 
vary and depend upon the data base organization specified for a 
particular OSAM data set. These functions are described in a subsequent 
Chapter of this manual. The other modules of IMS/VS interface with OSAM 
through OPEN, CLOSE, READ, and WRITE macro instructions similar to those 
provided for any OS/VS access method. OSAM modules interface with the 
OS/VS input/output supervisor through the EXCPVR macro instruction in 
VS1 and SVS and through the I/O driver interface in MVS. As far as 
OS/VS is concerned, an OSAM data set is described as data set 
organization equals physical sequential (DSORG=PS). In fact, an OSAM 
data set can be read using BSAM or QSAM. The advantages of OSAM to 
IMS/VS relative to either BSAM or BDAM are: 


1. An OSAM data set can occupy a maximum of 60 extents. If the data 
set resides on a Rotational Position Sensing (RPS) device and the 
number of records per track is greater than 7, the maximum number 
of extents decreases. A data set requiring a maximum sector 
table allows for a maximum of 52 extents. 


The Data Extent Block (DEB) for an OSAM data set contains 16 
bytes of OSAM information for each extent. In addition, a sector 
table is built for RPS devices. The length of the sector table 
is 8 bytes plus one byte for each data set record, rounded to a 
multiple of 8 bytes. A sector table exists for each unique 
device type. 


2. An OSAM data set can be opened for update in place and extension 
to the end through one data control block (DCB). The phrase, 
extension to the end, means that records may be added to the end 
of the data set and that new direct access extents may be 
obtained. 


3. An OSAM data set need not be formatted prior to use. 


4. An OSAM data set can have fixed length blocked or unblocked 
record format. 


5. File mark definition is always used to define the current end of 
the data set. The addition of a new block causes the file mark 
to be placed after the new block. This concept is used as a 
reliability aid while the OSAM data set is open. 
It should be remembered that other OS/VS access methods, VSAM, ISAM, 
and SAM are used for physical storage of data elements in addition to 
OSAM. 


OSAM data sets are restricted to a 31 bit addressing limit. 
Generalized Sequential Access Method (GSAM) 
The Generalized Sequential Access Method (GSAM) provides accessing 


Support for simple physical sequential data sets, such as tape files, 
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SYSIN, SYSOUT, and others that are not hierarchical. These are data 
sets which, before GSAM, could not be used as IMS/VS data sets. 


Support provided includes sequential or direct retrieval by a record 2 
identifier which defines the relative position of that record. 


Support is provided for both OS/VS Sequential Access Method (SAM) and 
OS/VS Virtual Storage Access Method (VSAM) for entry sequenced data sets 
(ESDS). GSAM is fully described in IMS/VS Application Proqramming 
Reference Manual. The concepts of hierarchy and segment described in 


this manual do not apply to GSAM. 
DATA BASE AND APPLICATION DESIGN DECISIONS 


DATA BASE DESCRIPTION (DBD) GENERATION 


Subsequent to IMS/VS system definition, DBD generations can be 
performed. A DBD must be provided for each data base to be used by an 
application program, prior to execution of the program. The IMS/V¥S 


Utilities Reference Manual describes the details of DBD generation. 

DBD generation is the execution of IMS/VS macro instructions to 
create a description of a data base. This data base description 
includes a definition of: 


e The data base organization and access method 

e Segment formats, whether fixed or variable 

e Whether the segments are subject to data compression routines 

e Inter-segment relationships 2 
e Field formats within segments 

e The existence of index relationships for any field 


e The relationships, if they exist, between segments in two or more 
data bases 


Figure 1-2 illustrates the execution of a DBD generation. The IMS/VS 
user creates control card statements that are presented to DBD 
generation as a normal OS/VS problem program job. The IMS/VS macro 
instructions used for DBD generation exist in IMSVS.MACLIB. The result 
of a DBD generation execution is the placement of the compiled DBD into 
IMSVS.DBDLIB as a member of the partitioned data set. The members of 
the IMSVS.DBDLIB library can be used during the Data Base System 
execution. 


A job control language procedure, named DBDGEN, is placed in the 
IMSVS.PROCLIB data set by IMS/VS system definition for subsequent DBD 
generation execution. This procedure is described in the IMS/VS System 
Programming Reference Manual. 
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Figure 1-2. DBD Generation Execution 


PROGRAM SPECIFICATION BLOCK (PSB) GENERATION 


The third necessary function prior to execution in the DB systen 
batch processing environment is PSB generation. Associated with any 
batch processing application program is a PSB control block. The PSB 
control block defines the data bases used by the application progran. 

In addition, it defines the manner in which the data bases are used 
(that is, retrieval only, retrieval and update, or data base create) and 
the segments within each data base to which the application program is 
sensitive. It also defines which, if any, additional secondary indexes 
can be used to assist in segment selection. 


PSB generation is the execution of IMS/VS macro instructions to 
define an application program's use of one or more data bases. The 
IMS/VS user creates control statements that are executed during PSB 
generation as a normal OS/VS job. The IMS/VS macro instructions used 
for PSB generation are in IMSVS.MACLIB. The result of PSB generation 
execution is the placement of the compiled PSB into IMSVS.PSBLIB as a 
member of the partitioned data set (Figure 1-3). The members of the 
IMSVS.PSBLIB data set are used during the Data Base's system execution. 
The IMSZVS Utilities Reference Manual describes the details of PSB 
generation. 


A procedure, named PSBGEN, is placed in the IMSVS.PROCLIB data set by 
IMS/VS system definition for subsequent PSB generation execution. This 
procedure is described in the IMS/VS System Programming Reference 
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Figure 1-3. PSB Generation Execution 


APPLICATION CONTROL BLOCKS (ACB) CREATION AND MAINTENANCE 


The fourth necessary function prior to execution of the data base 
System, is ACB creation and/or maintenance. This function is optional 
in a DB system. It is required in a DB/DC system. Associated with all J 
batch processing application programs are DL/I control blocks which 
define the data bases, structures, and methods to be used with a 
particular application. 


The information in these blocks can be constructed in either of two 
ways: (1) at initialization time, the logical block builder module 
(DFSDLBLO) is called to construct the blocks from the PSBs and DBDs 
associated with the application program to be scheduled; or (2) the 
Application Control Blocks Creation and Maintenance utility program 
(DFSUACBO) is used to prebuild the control blocks for the application 
program. In this case, the necessary control blocks are loaded directly 
from the IMSVS.ACBLIB data set, saving processing overhead. 


Application Control Blocks Creation and Maintenance requires no 
IMS/VS resources other than IMSVS.PSBLIB, IMSVS.DBDLIB, and 
IMSVS.ACBLIB. The user supplies control statements which specify the 
Operations to be performed. (See Figure 1-4.) The IMS/VS Utilities 


Reference Manual describes the details of ACB creation and maintenance. 


A procedure, named ACBGEN, is placed in the IMSVS.PROCLIB data set by 
IMS/VS system definition for subsequent ACB creation and/or maintenance. 


This procedure is described in the IMS/VS System Programming Reference 
Manual. 
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Figure 1-4. ACB Creation and/or Maintenance 


APPLICATION PROGRAM DESIGN 


The final function performed prior to DB system execution is the 
creation of application programs. Application programs are required to 
create and maintain all user-defined data bases. These programs are 
written in Assembler Language, COBOL, or PL/I, and must be placed in the 
IMSVS.PGMLIB data set after compilation and link edit. IMS/VS JCL 
procedures are available to the user for program compilation and link 
edit. These procedures are placed in the IMSVS.PROCLIB data set by 
IMS/VS system definition. Each compiled application program must be 
link-edited with modules that will be called by the application progran 
during execution. JCL procedures cause this link-edit to be performed. 
For details see chapter "The IMS/VS Procedure Library" in the IMS/VS 
System Programming Reference Manual. 


EXECUTION AND CONTROL OF THE DATA BASE SYSTEM 


This section of the chapter describes batch processing in the DB 
system. Prior to execution, the functions of IMS/VS system definition, 
DBD generation, PSB generation, and application program compilation, and 
optionally, ACB creation, are assumed to have been performed. 


ESSENTIAL PROGRAM ELEMENTS FOR EXECUTION 


Figure 1-5 illustrates the program elements necessary for batch 
execution. The IMS/VS control blocks are obtained from the IMSVS.ACRLIB 
{if prebuilt blocks are to be used) or are constructed dynamically at 
execution time from the PSBs and DBDs associated with the application 
program. The application program is obtained from the IMSVS.PGMLIB data 
set. The IMS/VS DB system modules are obtained from the IMSVS.RESLIB 
data set. 
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Figure 1-5. Essential Program Elements for Execution 


As previously described, there is a PSB associated with the batch 
processing application program. The PSB is composed of one or more 
Subordinate control blocks called data base program communication blocks 
(PCB). Each data base PCB specifies a data base or logical structure of 
data segments used by the application program. The PCB specifies the 
name of the DBD associated with the desired data base and the names of 
segments within the data base to which the program is sensitive. 
Secondary indexes can be specified to aid in segment selection. 

Segments to which an application program is sensitive can be retrieved, 
updated, inserted, and deleted. Segments to which an application is not 
sensitive are never presented to the application program. The concept 
of segment sensitivity provides some degree of data independence. 
Additional constraints can be placed on the manner in which an 
application program is sensitive to a segment. Levels of sensitivity 
can be defined for each segment. The lowest level of sensitivity is 
segment retrieval only. The next level of sensitivity allows segment 
retrieval, update, insert, or delete. 


Data Base Description Block (DBD) 

Each data base PCB in the PSB associated with the application program 
to be executed defines a DBD by name. This means that one or more DBDs 
are required for any batch program execution. Each DBD defines the 
organization and segment structure in its associated data base. The 
concept of a logical data base and associated DBD is defined ina 
subsequent chapter of this manual. If the DBD named in a data base PCB 
is associated with a logical data base, one or more additional DBDs are 
required to define the data base and identify the segments within the 
data base to which the program is sensitive. 
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Application Control Block (ACB) 


Together, the PSBs and DBDs are used to construct the IMS/VS 
application control blocks. This may be done dynamically or by a 
utility program which prebuilds the blocks. The IMS/VS Utilities 
Reference Manual describes this process. 


An application program to be executed in the batch processing DB 
system environment may be written in COBOL, PL/I, or Assembler Language. 
A subsequent chapter of this manual describes design considerations for 
an application program. The details of application progran 


Reference Manual. 


The IMS/VS modules utilized in the DB system environment are obtained 
from the IMSVS.RESLIB data set. These modules are placed in that data 
set by the execution of IMS/VS system definition. The majority of the 
modules are involved with handling data base requests from the 
application program. These modules in turn utilize the data management 
access method modules of VSAM, ISAM, OSAM, GSAM, and SAM. 

The primary IMS/VS modules are: 

Data Base Retrieval Module 

Data Base Insert Module 

Data Base Delete/Replace Module 

Data Base VSAM Interface Module 

Data Base ISAM Simulator Module 

Data Base Hierarchical Direct Space Management Module 
Data Base ISAM/OSAM Buffer Handler Module 

Data Base Buffer Handler Router Module 

Data Base Hierarchical Direct Index Maintenance Module 
GSAM Access Method Modules 

OSAM Access Method Modules 

Data Base Logging Modules 

A later chapter of this manual describes the IMS/VS data base access 
methods. Each of these data base access methods uses either standard 


OS/VS data management access methods or OSAM for the physical storage of 
segments. The following illustrates the relationships. 
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LOW LEVEL ACCESS METHOD 


USED _FOR PHYSICAL STORAGE 


HSAM QSAM or BSAM 

HISAM BISAM*?OSAM, QISAM-OSAM, or VSAM 
HDAM OSAM or VSAM 

HIDAM BISAM-OSAM, QISAM-OSAM, or VSAM 
GSAM BSAM or VSAM (ESDS only) 


If sequential processing of an HSAM data base is defined, QSAM is 


used in support of HSAM. 


If nonsequential processing of an HSAM data 


base is requested, BSAM is used in support of HSAM. When a HISAM data 


base is created or reorganized, 


QISAM load mode and OSAM are used. When 


an existing HISAM data base is used for retrieval, insert, update, 
and/or delete, QISAM scan mode and OSAM are employed. If a PSB 
generation defines two or more data base PCBs which relate to the same 


HISAM data base, 


update, 


segment storage when 


use of 


storage only. 


BISAM read and write are used for HISAM retrieval, 


delete, and/or insert. OSAM or VSAM is used for all data 


ISAM (BISAM or QISAM) in an HIDAM data 


the data base access method is HIDAM or HDAM. The 


base is for index segment 


The use of BISAM or QISAM in support of the HIDAM data 


base access method is equivalent to that described for HISAM. 


DATA BASE SYSTEM EXECUTION 


Once the functions of IMS/VS system definition, DBD generation, PSB 
generation, and application program creation have been accomplished, 
execution of the Data Base system may be performed. The initial DB 
system execution presumably loads data into one or more of the data 
bases previously defined by DBD generation. 
described in the IMS/VS Utilities Reference Manual.) Subsequent 


(The load process is 


executions would perform retrieval, update, insert, and/or delete 
Operations against existing data bases and/or create additional data 


bases. 


When a batch processing execution of the DB system is initiated, the 
control blocks associated with the application program must be obtained 


and initialized. 


This control block initialization process is part of 


the batch processing job step execution but precedes the loading of the 
application program. The first step involves 
If PARM=DBB was specified, the required control blocks are 
obtained from IMSVS.ACBLIB by the block loader module. If PARM=DLI was 
specified, the block builder module is called to construct blocks 
dynamically. In this case, IMSVS.PSBLIB and IMSVS.DBDLIB are used to 
the required PSBs and DBDs. Once the blocks have been obtained, 
the initialization routines load the required DL/I action modules, 
initialize STAE, and format the necessary storage areas in preparation 
for loading and giving the application program control. Figure 1-6 
illustrates this initialization process. 


blocks. 


obtain 
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Obtaining the DL/I control 
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Figure 1-6. Initializing the Batch Data Base System, Step One 


The IMS/VS module which controls the DB system environment is called 
the program controller. The primary functions of the program controller 
ares 


e® Initiate the IMS/VS DB system block building process by passing 
control to the IMS/VS control block building modules (Figure 1-6). 


e Initiate the DB system DL/I and data base logging modules and pass 
control to the user's application program (Figure 1-6). 


e Terminate the DB system execution by returning to OS/VS. 


The EXEC statement provided as part of the OS/VS job control language 
for the DB system batch processing execution includes, within the values 
of its PARM= operand, the names of the PSB and the application program 
to be executed. Control is passed from the region controller (not shown 
in Figure 1-6) to the program controller, to the block loading and 
building modules. The name of the PSB is supplied. Using the PSB name, 
the required control blocks are obtained. If the first PARM= value is 
DBB, the required control blocks are loaded from the IMSVS.ACBLIB data 
set. If the first PARM= value is DLI, the named PSB is loaded from the 
IMSVS.PSBLIB data set and referenced DBDs are loaded from the 
IMSVS.DBDLIB data set. From the PSB and DBD control blocks, internal 
IMS/VS control blocks are built for subsequent input/output operations 
in the DB system environment. 


After the control block construction is complete, control within the 
OS/VS address space is returned to the program controller. At this 
point the remainder of the DB system functions are initialized [Figure 
1-7). This includes loading of the required DL/I data base modules, 
loading of the data base log modules, creation of a data base buffer 
pool, and loading of the required data management access method modules. 


Design and Installation of a DB System 1.13 


Depending upon the data base organizations and the manner in which 
each data base is used by the application program, only the necessary 
DL/I and access method modules are loaded. 


Finally, the application program to be executed is obtained from the 
application program library, IMSVS.PGMLIB. Control is given to the 
application progran. 













PROGRAM 
CONTROLLER 


APPLICATION 
PROGRAM 






LIBRARY 




























IMSVS.PGMLIB 
IMS/VS DATA 
SYSTEM DATA | BASE CONTROL 
LIBRARY LANGUAGE/I. | | OGGING BLOCKS 
IMSVS.RESLIB 
DATA BASE 
BUFFER POOL 
Figure 1-7. Initializing the Batch Data Base System, Step Two 


Data Base System JCL Considerations 


IMS/VS provides procedures for DB system batch processing execution. 
They are DLIBATCH, DBBBATCH, IMSPLIGO, and IMSCOBGO. They are placed in 
IMSVS.PROCLIB during IMS/VS system definition. These procedures are 
described in detail in the IMS/VS System Programming Reference Manual 
and include the basic JCL for execution. The user must add DD 
statements for all data bases to be used. The content and format of 
these DD statements are described in the "DBD Generation Control 


Data Base System Control Sequence Flow 


Figure 1-8 illustrates the DB system control sequence flow once the 
application program has been given control. Upon entry to the 
application program, a parameter address list is provided. The 
addresses in this list provide visibility to each data base PCB in the 
PSB for the application program (see arrow 1). These data base PCB 
addresses are subsequently used by the application program when issuing 
data base input/output call requests. 
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Figure 1-8. Data Base System Flow 


Arrows 2 and 3 in Figure 1-8 indicate the transaction input and 
response output interface with the application progran. 


All application programs operating under IMS/VS have a language 
interface link-edited with the application program. The language 
interface accepts a data base call from the application program and 
passes control to the DL/I data base modules (arrow 4). 


The purpose of the language interface is to provide a consistent 
format to DL/I for all data base call requests, independent of the 
programming language used to write the application program. The 
IMS/VS-supplied OS/VS procedures for compiling and link editing 
application programs are described in section "Procedure Library" in 
chapter “The IMS/VS Procedure Library" in IMS/VS System Programming 
Reference Manual. The link edit step for each of these procedures 
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provides for the inclusion of the language interface with the correctly 
compiled PL/I, COBOL, or Assembler Language application program. 


The language interface function of IMS/VS is reenterable and is 
upwardly compatible with that of IMS/360 Version 2. To take advantage 
of the reenterable capability of the IMS/VS language interface, 
application modules from IMS/360 installations must be re-link-edited, 
replacing the IMS/360 language interface with the IMS/VS language 
interface. 


After control is passed to the DL/I modules for execution of the data 
base call request, the following functions are performed. 


1. The parameters in the call request are checked for valid content. 
This checking involves the use of data base PCBs [arrow 5) and 
DBDs (arrow 6). 


2. If the data base call involves segment retrieval, the information 
contained in control blocks and data base buffers is used to 
attempt to satisfy the request. If the request can be satisfied, 
the desired data segment is placed in the input/output work area 
of the application program provided in the data base call. 


3. If the retrieval request cannot be satisfied with information 
already contained in the data base buffer pool, the appropriate 
data management access method modules are invoked (arrow 7), and 
the data management access method modules perform the necessary 
input reguests to place necessary data in the data base buffer 
pool [arrow 8). 


4. If the data base call request involves data segment update or 
deletion, the segment must first be retrieved (from either the 
buffer pool or secondary storage). Subsequently, the segment is 
deleted or updated (arrow 10). 


5. If the data base call request involves data segment insertion, 
the segment is placed in the data base buffer pool and 
subsequently written to direct access storage (arrow 10). 


6. When the data base call request involves segment insertion, 
updating, or deleting, a record of the data base modification is 
placed on an IMS/VS log for the batch address space (region) 
execution. This logical information can subsequently be used for 
data base recovery or reconstruction (arrow 9). 


TR ARS 2 OR A A EEE te EY TE SR DY 


IMS/VS maintains two data base buffering functions: one for VSAM data 
bases, and one for ISAM/OSAM data bases.e A separate pool of buffers is 
allocated for each type of data base (VSAM and ISAM/OSAM) and the data 
Management access methods {VSAM, ISAM, and OSAM) are directed to read 
into and write from these buffers. 


The concept of the buffer pool is to allow blocks of data to remain 
in main storage as long as possible to avoid secondary storage reads and 
writes. Data in the buffer pool can be accessed and updated without 1/0 
as long as there is no need to reuse the buffer space the data occupies. 
A use chain determines the order in which the buffers are used. Empty 
buffers are placed at the bottom of the use chain and are always 
available for reuse. As buffers are accessed, they are placed at the 
top of the use chain. When a retrieve request occurs, the buffer pool 
is searched using the use chain (for ISAM/OSAM a hash table is used to 
direct the search), to determine if the requested data is already in 
main storage. If the data is not found, the least recently used buffer 
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{bottom of the use chain) is selected, the old data is written out if it 
has been changed, and the requested data is read into the selected 
buffer. 


The size of the data base buffer pools can have a significant effect 
on the performance of the IMS/VS system. The size of the buffer pool is 
defined during DL/I initialization, based on control statements provided 
by the user (see the section “Defining the IMS/VS Buffer Pool" in the 
IMS/VS Instaliation Guide). The size of the ISAM/OSAM buffer pool, for 


IMS batch jobs, can be defined by the BUF parameter on the EXEC 
statement for the job step or by buffer control statements. 


At the beginning of each of the data base buffer pools, there exists 
a work area used by IMS/VS to record statistics on the activity in the 
pool. These statistics are of value to the IMS/VS user in determining 
the appropriate buffer pool size for a given application program. The 
DL/I statistics call (STAT) can be used to obtain these statistics in an 


DATA BASE LOGGING 


All modifications to any data base used in the DB system environment 
are recorded on the IMS/VS log tape for the address space. If multiple 
data base system executions are performed concurrently under OS/VS1 or 
VS2 a separate IMS/VS log tape is associated with each address space. 
Unless a data base is being used for retrieval purposes only in all 
address spaces accessing the data base, no attempt should be made to 
access the same data base from more than one OS/VS address space at any 
one time. 


Data base logging provides the IMS/VS system user with a recording of 
all modifications to all data bases used during a data base execution. 
The log can be written with BSAM or OSAM. See "Chapter 2. Log Facility" 
improvement considerations using OSAM. An IMS/VS option, log-tape 
write-ahead, insures that log records are written before the data in the 
data base is changed. See the section "DL/I Data Base Buffering 
additional information on log-tape write~-ahead. The IMS/VS log tapes 
can be used in conjunction with the IMS/VS Data Base recovery utility to 
rebuild a data base. The IMS/VS Utilities Reference Manual provides 
details on the use of data base log information for recovery. 


If no data base changes will be made or if no data base recovery 
utilities will be used, the logging function can be made inoperable by 
specifying DD DUMMY on the primary log DD statement {DD name IEFRDER). 
If dual system logs are used and the primary log is specified as DD 
DUMMY the secondary log is ignored and no logging is done. 


If a data base is destroyed because of input/output errors, it can he 
restored with the following procedure. 


e Restore the data base with a previously dumped copy. The Data Base 


Recovery utilities can be used for this purpose. Refer to the 
IMS/VS Utilities Reference Manual for detailed information. 
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e Apply all data base modifications made to the data base since the 
dumped copy was created. The IMS/VS Data Base Recovery utility 
programs provide this function. 


e Repeat the current DB system processing from the beginning. 


Note: The above discussion of data base logging and recovery does not 
apply to the HSAM organization. Since the old data is not destroyed 
when updating HSAM, logging and backout are not required to maintain 
data base integrity. 


BATCH CHECKPOINT/RESTART 
The batch checkpoint facility provides for synchronizing checkpoints. 


The CHKP function call to DL/I allows the coordination of program 
activity with data base activity. Lacking any means to identify 
Significant events in an application program, DL/I treats data base 
calis as one continuous string of related actions. When a CHKP call is 
issued, the program is indicating to DL/I that a sync point has been 
reached and the data base buffers should be written to secondary 
storage. For batch programs, a checkpoint record is also recorded on 
the log data set to indicate the sync point and set the maximum point to 
which the data base backout occurs if it becomes necessary. 


In the batch environment, the duration of the job may be long and the 
number of data base changes may be large. If the job lasts for many 
hours then the time for reloading direct access data sets and rerunning, 
if necessary, may be excessive. Batch checkpoint/restart allows the 
user to take one or more sync points during execution. The sync point 
then determines the amount of time required to backout the data base if 
restart occurs. Backout is effected only back to a specified checkpoint 
record. 


The action taken by the DB system for batch programs when a CHKP call 
is issued is as follows: 


1. Altered data base buffers are written. 


2. The checkpoint ID supplied in the CHKP call is written to the log 
tape. 


3. If OS checkpoint/restart is used, the checkpoint ID must be 
unique for all checkpoints issued by this application progran. 
If IMS/VS expanded checkpoint/restart facility is used, the 
checkpoint ID must be unigue for all checkpoints in the IMS/VS 
systen. 


4. Message DFS681I, containing the checkpoint ID supplied, is sent 
by a WTO to the system console, and to the programmer. 


5. Optionally, an OS/VS checkpoint of the user's region is taken. 
If the IMS/VS log access method is OSAM, the OS/VS checkpoint is 
not taken. 


It is the user's responsibility to checkpoint any non-IMS/VS 
information or data sets (such as transaction/response data sets) with 
issuance of the CHKP call. This can be done with the OS/VS 
checkpoint/restart option in the DL/I CHKP call. 
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As an alternative to the OS/VS checkpoint/restart option, the user 
can specify the IMS/VS extended checkpoint/restart facility. This 
consists of a restart call (function code XRST) and optional parameters 
on the CHKP call. If used, the XRST call is the first call to IMS/VS 
issued by the user program. If a restart is not in progress, the XRST 
call is effectively a NOP. 


The issuance of an XRST call causes the following action to be taken 
for subsequent CHKP calls issued by the progran: 


1. Optionally, user specified areas, that is, application variables, 
control tables, and position information for non-IMS/VS data 
sets, are recorded on the IMS/VS log. 


2. The fully qualified key of the last record processed by the 
program on each IMS/VS data base is recorded on the log. 


3. The functions of the standard CHKP call are performed, except 
that the OS/VS checkpoint of the user's region is not taken. The 
user has the option of using OS/VS Checkpoint/Restart, or the 
IMS/VS restart (XRST call), or neither, but not both. 


Batch Backout Utility Program 

A checkpoint ID can be supplied to the IMS/VS Batch Backout utility 
program through a control statement. The backout of data segments from 
the data base is done from the end of the log tape until the matching 


checkpoint record is encountered. 


In the case of a batch program, the checkpoint/restart facility used 
can then be invoked to restart the program from that point. 


The batch checkpoint facility is implemented by the use of the CHKP 
system service call from the application program. This call is used to 
indicate a sync point at which any data base updates can be restarted. 
The actual checkpointing of the batch program environment and the 
routine used to restart it are at the option of the user. The DL/I 
checkpoint program cannot issue the OS CHKPT macro. 


If the DL/I user chooses to write his own checkpoint/restart 
routines, he must: 


e Record application variables and control tables. 

® Record position information for non-IMS/VS data sets. 

e Provide a restart entry point and reinitialization procedure. 
e Initialize IMS/VS control blocks, for example, PXPARMS. 


Use of the XRST call and user area parameters on the CHKP call 
Simplifies the task for the user writing his own restart routines. 


°e A restart situation is indicated by specifying a checkpoint ID in 
the PARM field (on the EXEC statement in the JCL) or in the XRST 
call itself. 

e Normal entry point and initialization procedures are used. 


e User areas recorded at checkpoint time are restored. 


Design and Installation of a DB Systen 1.19 





A GET UNIQUE is issued for each GSAM data base for the last used 
record, if the data base was open at the time the checkpoint was 
taken. 


e No data is returned as the result of the GU, but key feedback and 
status codes are saved in the user PCBs. 


e If the data base was opened for output, then a PNT function code, 
reguesting POINT, is used. 


e GSAM data bases are automatically repositioned at restart if the 
XRST call is used. 


e The checkpoint ID is returned to the user program to allow it to 
link to its own restart subroutine. 


Batch programs that do not utilize the batch checkpoint facility 
Should be reprogrammed to do sow The major advantage comes fron 
Significantly shorter backout runs after failure, and the ability to 
terminate a long running job and restart it at a current point with very 
small backout preparation and minimal rerun time. 


IMS/VS USE OF STAE/ESTAE 


IMS/VS makes use of STAE/ESTAE routines in the control region, the 
dependent message (MPP,BMP,IFP) regions, and the DL/I batch regions. 
The control region STAE/ESTAE routines ensure that data base logging and 
various resource cleanup functions are completed. In the dependent 
message region, STAE/ESTAE is used to notify the control region of any 
abnormal termination of the application program and/or the dependent 
message region itself. 


If an application program uses STAE/ESTAE, the following rules must 
be observed: 


e Establish the STAE/ESTAE only once, before the first DL/I call. 


- It is not recommended that the application program use the RETRY 
option when exiting from the STAE/ESTAE routine but return a 
CONTINUE WITH TERMINATION indicator at the end of the STAE/ESTAE 
processing. If the STAE/ESTAE routine does exit specifying the 
RETRY option, the retry routine must ABEND with the original 
abend code. The original error data in the System Diagnostic 
Work Area (SDWA) may not be available for the IMS/VS exit 
routines if the RETRY option is selected. 


e The PL/I STAE exit options do not include the CONTINOE WITH 
TERMINATION option. Applications written in PL/I must not use the 
PL/I STAE option. 


The user STAE/ESTAE exit routine must not issue DL/I calls since the 
original abend may have been caused by a problem between the application 
program and IMS. This would result in a recursive abend with a 
potential loss of data base integrity or problems in taking a 
checkpoint. 


Note: Programs that are OS/VS subtasks of an application program called 


by IMS/VS must not issue DL/I calls. If they do, the results will be 
unpredictable. 
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IBM SYSTEM/370 POWER WARNING FEATURE SUPPORT 


The IMS/VS Power Warning Log Terminator program supports the power 
warning feature on System/370 Models 158 and 168. This support enables 
the user to close the IMS/VS log from a dump data set without having to 
restore memory. The procedure used to accomplish this is described in 
the IMS/VS Operator's Reference Manual. 


IMS/VS DB MONITOR 


The IMS/VS DB monitor is a tool for collecting performance data to 
investigate specific application designs, data base designs, and 
resource allocations. It consists of a monitor module, and a Monitor 
Report Print program. When activated, it analyzes and records the 
internal activities of the IMS/VS DB system. The monitor report print 
program is processed offline to produce reports that summarize and 
categorize, at various levels of detail, the information recorded by the 
monitor module. The actions required to activate the monitor module are 
described in the IMS/VS Operator's Reference Manual. The monitor report 
print program is described in the IMS/VS Utilities Reference Manual. 


The monitor module collects data from IMS/VS control blocks during 
Operation of the batch systen (with minimum interference to the system) 
and records the data either on an independent data set or on the IMS 
log. The monitor remains resident and is activated and deactivated 
through the system console. 


The following are recommendations for use of the DB monitor: 


e Collecting data -- The DB Monitor enables an IMS/VS user to collect 
performance data to assist in analyzing an existing IMS/VS batch 
system. The amount of data collected and the analysis time to 
understand the report output suggest short traces during various 
time periods. Reports produced from profiles of a batch execution 
considered as normal can be used as a profile and compared with 
reports produced during a batch execution with unusual performance 
characteristics. 


e Tuning system -- The DB Monitor can be used to quantify the effect 
of actual changes to data base structures, program characteristics, 
data set placement, and pool sizes. 


e Testing application -- In the final testing of new or revised 
applications, the DB Monitor can be useful in validating the 
internal operation of the programs and data bases. For example, the 
programmer thought a specific DL/I call could be satisfied with a 
Single I/O retrieval, yet the DL/I call report indicated a large 
data base scan as shown by many IWAITs. Investigation of such items 
could assist in determining whether a new or revised application 
meets the performance objectives. Data contained in the reports may 
also assist in defining the resources required by an application 
progran. 
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This chapter concerns the decisions and planning that must precede 
the installation and use of the IMS/VS Data Base/Data Communication 
(DB/DC) system. Familiarity with Chapter 1 of this manual is assumed. 


For the most part, the design and control considerations of a Data 
Base system, as discussed in chapter t, are applicable to the combined 
DB/DC (Data Base/Data Communication) system discussed in this chapter. 
The fundamental differences in the data base oriented considerations, 
when viewed from within the combined DB/DC environment, have to do with 
multiplicity and interaction. [In the Data Base system, for example, 
only one program and its associated program specification block are used 
at a time. In the DB/YDC system, planning must consider that multiple 
programs and their associated control blocks may be in use at the same 
time. Furthermore, the interactive effects among those multiple 
programs and control blocks must be considered. This kind of 
relationship applies, as well, to other resources managed in the DB/DC 
system; such as data base buffers, data base control blocks, terminal 
buffers, and message processing regions. 


The contents of this chapter provide guidance in: 
e Selecting an OS/VS configuration 

e Selecting an IMS/VS configuration 

e Establishing a message scheduling algorithn 


e Selecting and configuring a physical terminal network 


Establishing a logical terminal network 


| ORGANIZATION OF DBZDC PROCESSING 


Regions are distinguished by the kind of processing performed within 
them. There are several kinds of regions: the IMS/VS control (CTL), 
Message Processing Program (MPP), Batch Message Processing (BMP), IMS/VS 
Fast Path Processing ({IFP), and batch. Note the distinction between 
batch processing using a local control program, and batch processing 
through the online control program. The local use of the control 
program is batch processing, provided by the DB system of IMS/VS. The 
use of the online control program to support batch-oriented operations 
is called batch-message processing. 


REGION TYPES 


For the online environment the region types that are utilized are the 
Control, Message Processing, Batch Message Processing, and Fast Path 
regions. The major types of processing programs are: control, message, 
batch-message, and Fast Path. 


the IMS/VS control program is normally started by using the OS/VS 


START command. It can also be started as a system task or as a job step 
using JCL. 
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The dependent regions are initiated by using the OS/VS START or the 
IMS/VS START REGION command. This results in JCL being read from a 
procedure library which initiates the dependent region. The dependent 
regions can also be started as a job step using JCL. i 


The Message Processing Program (MPP) region is initiated by the OS/VS 
job management facilities. The MPP region can contain an application 
program for processing against data bases in the online manner. 


The Batch Message Processing (BMP) region can contain an application 
program for processing against data bases in a batch processing 
operation. The application program in the batch region is scheduled by 
OS/VS job management, but may utilize DL/I for data base reference. An 
application program executed in a BMP region can access only IMS/VS and 
Fast Path data bases that are defined in the IMS/VS control region. 


A BMP region, in addition to being able to process data bases used 
for message processing, has access to input message queues and can 
provide output the the message queues. Access to the input message 
queues is provided by specifying, in the JCL for a BMP region, a 
transaction code to which access 1s wanted. Access to the output 
message queues is provided by specifying output terminal PCBs in the PSB 
for the application program that executes in the BMP region. 


When the data bases normally used for message processing are not 
being used for that purpose, they can be processing in a batch 
processing region as described in the chapter "Design, Installation, and 
Maintenance of the IMS/VS Data Base System." This can be done when the 
IMS/VS control program is not operating as an OS/VS job or the data 
bases are deallocated using the /DBR command (MVS only). 


The IMS/VS Fast Path Processing ({IFP) region executes as a dependent 
region of the IMS/VS control region only. The IPP regions are handled | 
differently depending on the type of program that is running in this j 
region. There are three uses for the regions in which Fast Path . 
processing is done: 


e Applications for processing Fast Path messages, termed 
message-driven programs. 


® Applications for processing input external to Fast Path, termed 
non-message-driven programs. 


e Utilities processed against Fast Path data bases. Past Path 
application programs can retrieve from as well as update DL/I data 
bases. 


The Data Language/I (DLI) region operates in a batch processing mode 
without accessing the message queues. DL/I calls that are directed toa 
specific PCB are passed to IMS/VS for processing. IMS/VS Batch 
applications have no access to Fast Path data bases. For more 
information on DL/I, see Chapter 1 in this publication. 


There are other batch region types in addition to those mentioned 
above, namely Data Base Batch (DBB) and IMS/VS Utility {ULU). 
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CONFIGURING THE SYSTEM THROUGH OPTIONS 


OS/VS OPTIONS 


Fixed or Variable Tasking 


The selection of an OS/VS configuration has some effect on the 
potential performance and reliability and availability characteristics 
of IMS/VS. Certain options are required by IMS/VS in all of the 
applicable configurations. The functional characteristics of IMS/VS, 
based on the use of these options, are identical regardless of the OS/VS 
configuration selected. 


The IMS/VS DB/DC system runs under OS/VS1 and OS/VS2. 


IMSZVS Program Module Preload Function 


OS/VS, IMS/VS, and application programs that will run in regions of 
IMS/VS can be made permanently resident in virtual storage. This can 
Significantly improve throughput and response time for frequently 
referenced transactions, if sufficient virtual storage is available with 
high performance paging DASD. 


Programs can be made permanently resident in two ways: 
1. In LINKPACK/RAM 


a. These programs are shared among all regions, resulting in a 
saving of virtual storage space. Initial access can be slow 
because the region JOBPACK and STEPLIB/JOBLIB are searched 
before LINKPACK is searched. Subsequent access can be at CPU 
speeds, if the region JOBPACK has not been purged by OS/VS 
Space management (this would be the case if sufficient 
virtual storage were not available to satisfy a user request 
for space). This can be altered by specifying SRCH=1 in the 
IMS procedure. For more information on the IMS procedure, 


System Programming Reference Manual. 
b. These programs are made resident by the same nethod used for 
OS/VS and IMS/VS modules. 


Ce. Application modules with names identical to PS8s should not 
be placed in OS/VS LINKPACK, since this causes a conflict 
during the ACB generation process. 


2. In REGION/PARTITION 


ae These program modules are used only for transactions serviced 
by the region involved, and only for the duration of that 
region. 


b. Because these modules are in the region JOBPACK, they are 
invoked without repeating the overhead of searching 
STEPLIB/JOBLIB, LINKPACK, and SYS1.LINKLIB. The overhead of 
fetching the module into virtual storage is encountered only 
at region initialization time. 


Cc. They are made resident by invoking the IMS/VS Program Module 
Preload function via the step execution JCL parameter. 


Design and Control of a DB/DC System 2.3 


d. In addition to those modules automatically preloaded into the 
IMS/VS control region, other OS/VS and IMS/VS modules can be 
made resident in the IMS/VS control region by using Module 


Preload. ; 


e. Module Preload can also be used for modules resident in 
LINKPACK/RAM. Thus, although the modules are physically 
residing in LINKPACK {and are being shared among multiple 
regions), the overhead involved in searching progran 
libraries and LINKPACK are only experienced at region 
initiation. 


Serially reusable programs can be resident only in the 
region/partition. They are made resident by invoking the Module Preload 
function via the step execution JCL parameter. 


The OS/VS task under which modules are preloaded varies based on the 
IMS/VS region type: 


IMS/VS5 Region Type OS/VS Task 

Control (CTL) Physical Log 

Message (MSG) Region Control 

Batch Message (BMP) Region/Program Control 
Batch (DLI) Region/Program Control 
Fast Path (IFP) Region Control 


If modules are preloaded into MPPs, the following performance 
considerations apply: 


1. Preloaded applications are invoked via the BRANCH instruction; ; 
this avoids OS overhead. 


2. Applications that are not preloaded and that have not heen 
previously invoked are located by issuing the BLDL macro 
instruction; this reduces operating system overhead by avoiding a 
PDS directory search for the application modules in subsequent 
scheduling. The maximum number of BLDL entries in the BLDL list 
can be specified in the PARM field of the MSG region JCL. The 
entries are kept in the list on the basis of: 


a. most recently referenced 
b. most often referenced 


3. All non-reentrant preloaded modules are reloaded after each 
abnormal termination. 


4. If an abnormal termination with DUMP occurs, all preloaded 
modules will be printed. 
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IMS/VS IN AN OS/VS SYSTEM 


OS/VS2 Oos/V¥S2 
IMS/VS_FEATURES OS/¥S1 _-SVS_ NWS. 
MSC 
BSC connection X x 
CTC connection x 
Main-storage-to-main-storage 
connection X x 
Fast Path X X 
Data Base Surveyor X X x 
OS/VS1 OS/VS2 (SVS) OS/VS2 (MVS) 
IMS/VS_Reqion Type -V=V_0 0 _____V=¥__0__ ___W=W_SWAP__ 
CONTROL X x X 
MESSAGE X X x 
BATCH-MESSAGE X xX X 
BATCH X x x 
FAST PATH X x 


* IMS/VS determines whether a batch region is swapped regardless of 
whether the user specifies the region as being swappabie. Tox 
IMS/VS, a batch region is swappable if it has not log, and it is 
not swappable if it has a log. 


OS/VS OPTIONS REQUIRED OR RECOMMENDED FOR IMS/SVS 


Many of the OS/VS system generation macro instructions must specify 
certain options and values to support an IMS/VS DB/DC systen. 


Certain OS/VS options are not reguired by IMS/VS, but are recommended 
for various reasons. For a full discussion of the required or 
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Not2 that IMS/VS supplies a user type 2 SVC that is nucleus-resideant. 
If the IMS/VS SVC is available at OS/VS system generation, it is 
convenient to incorporate it by using the RESMODS macro instruction. 


SPECIAL ACCESS METHOD -- OSAM 


The functions and operations of OSAM described for the Data Base 
system in chapter 1 of this publication also apply to the DB/DC systen. 
The DB/DC system uses OSAM for message queue management. Further 
discussion of message queue management appears later in this chapter. 


Allocation of OSAM Data Sets 


The normal mode of OSAM data set allocation is through the use of the 
JCL at the time the data set is loaded. This can be for single or 
multiple volumes, and is done using the SPACE parameter. This is the 
recommended method. 


If the installation control of direct access storage space and 
volumes is such that the OSAM data sets must be preallocated, or if it 
is decided that a message queue data set will require more than one 
volume, the OSAM data sets may be preallocated. 
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Preallocation is done by any of the accepted methods, with the 
following restrictions: 


e DCB parameters should not be specified. 


e If the data set is to be expanded beyond the preallocated space, a 
secondary quantity must be specified during preallocation. Note 
that queue data sets will not be extended beyond their initial or 
pre-allocated space guantity. 


allocation should allocate extents on all of the volumes to be used, and 
guarantee that the end of the data set is correctly indicated in the 
DSCB on the last volume. 


The suggested method is to use the IEFBR14 utility once for each 
vOlume on which space is desired. Do not simply use IEFBRI4 and specify 
a DD card for a multi-volume data set. This will put an extent on the 
first volume only and will not indicate that the volume is the last 
volume of the data set. 


//OSAMALLO JOB A,OSAMEXAMPLE 
//S\ EXEC PGM=IEFBR1IG 

//SYSPRINT DD SYSOUT=A 

//EXTENT1 DD VOL=SER=AAAAAA,SPACE= (CYL, (20,5)) ,UNIT=3330, 
// DSN=OSAM. SPACE, DISP={, KEEP) 

//S2. EXEC PGM=IEFBRI14 

//SYSPRINT DD SYSOUT=A 

//EXTENT2 DD VOL=SER=BBBBBB,SPACE=(CYL, (30,5)) , UNIT=3330, 
If DSN=OSAM, SPACE, DIS P= {, KEEP) 


J/LAST EXEC PGM=IEFBR14 

//SYSPRINT ODD SYSOUT=A 

//EXTENTL DD VOL=SER=LLLLLL, SPACE=(CYL, (30,5)) ,UNIT=3330, 
// DSN=OSAM. SPACE, DISP=([(, KEEP) 


Notes: 
1. Secondary allocation must be specified for all volumes if the data 
set is to be extended beyond the initial allocation. 


2- Secondary allocation is not allowed for queue data sets; they can 
have multi-volume allocation however. 


3. If the OSAM data set must be cataloged, use IEHPROGM or Access Method 
Services to ensure that all volumes are included in the catalog 
entry. 


Cautions: 

1. Do not preallocate more volumes for OSAM data set extents than will 
be used during the initial load or reload process. Doing so may 
cause performance problems during a later OPEN process since OSAM 
will not have a valid end-fo-file (EOF) mark in the last volumes 
DSCB. This will force OSAM to SCAN the entire data base in order to 
find the true EOF mark. Since all extents of system data sets are 
formatted at OPEN, the above caution does not apply to message queue 
data sets. 
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If your (re)load process does not put the EOF mark on the last 
volume, you can add and delete dummy records to the end of the data 
set to force the EOF mark to the last volume. 


2. Do not reuse multi-volume OSAM data set extents without scratching 
and reallocating the space first. If this is not done, an invalid 
EOP mark may be left in the DSCB of the last volume of the data set, 
for instance after an unload/reload [reorganization). This will 
cause OSAM to improperly open the data set after IMS/VS utilities 
have operated against the data set. fhis will result in an imbedded 
EOF mark somewhere in the middle of the data base. For instance, a 
data set may be allocated on three volumes, with the EOF mark on the 
third volume, but after reorganization, the data set may require only 
the first two volumes, and therefore the new EOF mark would be placed 
on the second volume. Since OSAM always checks the last volume's 
DSCB for an EOF mark during OPEN processing, normal processing would 
use the old EOF mark in the DSCB on the third volume. Subsequent 
segment inserts would go after the old EOF mark on the third volume. 
A later image copy will use the reorganization reload EOF mark on the 
second volume as true EOF indication since it processes the data set 
sequentially, thus, ignoring the new data on volume three. 


TMSZVS FACILITIES 


Configuring the IMS/VS system for a particular user environment is 
accomplished through IMS/VS system definition. IMS/VS system definition 
consists of macro statements, the operands of which tailor the IMS/VS 
system for the user. The next several sections of this chapter discuss 
the design considerations in selecting various system definition 
Options. You may wish to subsequently review this chapter with the 
system definition details in the IMS/VS Installation Guide. 
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The specification of maximum processing regions places a limit upon 
processing capabilities that can be changed through redefinition or 
through specifying the PST parameter in the IMS procedure referenced 
above. The value assigned to the MAXREGN keyword of the IMSCTRL macro 
statement includes Fast Path, message, and batch message processing 
regions. The maximum number of regions specified influences the 
calculation of maximum I/O reguests. The largest value that can he 
specified is 15. 


ie ED a a 


The specification of active I/O requests is one of the system-related 
specifications that directly influences the performance potential of the 
DB/DC system. It governs the maximum number of I/O requests outstanding 
at any time. You must specify a value on the MAXIO keyword of the 
IMSCTRL statement that exceeds, by at least two, the maximum number of 
regions that can be executing concurrently. It is recommended that the 
value be one-half the sum of the number of communication lines, plus the 
number of concurrently operating processing regions. This number should 
reflect a prediction of maximum to average number of active 
communication lines. If the autopoll feature is used, it should be 
possible to reduce the assigned value without significantly affecting 
performance. The largest value that can be specified on the MAXIO 
keyword is 255. 
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Checkpoint Frequency 


The selection of a checkpoint frequency should be influenced by 
anticipated message and data base processing activity, and the need for 
rapid restart. The frequency value chosen determines the number of log 
records that are written between automatic environment checkpoints. 
Whatever the value chosen, it is somewhat self-adjusting to system 
processing rates. That is, as more messages and data base update 
activities are processed, more log records are written. Hence, 
automatic checkpoints occur more frequently. 


System Queue Space 


System queue space must be sufficient to support the requirements of 
the OS/VS control blocks necessary for the operation of an IMS/¥S 
system. See "IMS/VS Storage Estimates" in the IMS/VS System Programming 
Reference Manual for the information necessary to estimate the required 
System queue space. 


INS/VS Enqueue/Dequeue 


Main storage is obtained dynamically within the control region by the 
IMS/VS enqueue/dequeue routines, The maximum amount of main storage 
that these routines obtain, and the maximum that these routines keep on 
an internal free chain, are specified by the CORE keyword in the IMSCTF 
macro statement. 


Under the program isolation concept, all activity (data base 
modifications and message creation) of an application program active in 
the DB/DC system is isolated from any other application program(s) 
active in the system until that application program commits, by reaching 
a synchronization point, that the data it has modified or created is 
valid. 


This concept makes it possible to dynamically back out the activities 
of an application program that terminates abnormally, without affecting 
the integrity of the data bases controlled by IMS/VS. It does not 
affect the activity performed by the other application program(s) 
processing concurrently in the system. 


With program isolation and the dynamic backout facility, it is 
possible to provide data base segment occurrence level control to 
application programs. A means is provided for resolving possible 
deadlock situations in a manner transparent to the application progran. 
The deadlock situation is detected by an IMS/VS routine called Exclusive 
Control Engueue/Dequeue. Upon detecting a deadlock situation, one of 
the application programs involved in the deadlock is abnormally 
terminated with a special] abnormal termination code. The abnormal 
termination causes the activity of the terminated program to be 
dynamically backed out to a previous synchronization point. Its held 
resources are freed. This allows the other program(s) to process to 
completion. The special code causes the transaction that was being 
processed to be saved. The application program is rescheduled. This 
process is transparent to application programs. 


Performance is enhanced by allowing control of data base updates to 
be maintained dynamically, as opposed to establishing the control at 
message scheduling time. This dynamic maintenance is controlled by the 
DL/I action modules through the use of the IMS/VS Enqueus/Dequeue 
routine. During the scheduling process, an analysis is made of the 
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intent of an application program toward the data base it uses. If a 
conflict exists with the data base usage of a currently scheduled 
transaction, the scheduling process must select another transaction code 
and try again. 


MESSAGE SCHEDULING 


Within IMS/VS each input message type is declared through system 
definition. Message types are called “transaction codes" or 
"transactions." At the time a transaction code is declared, many 
Optional attributes can be selected. These attributes, either directly 
or indirectly, affect the schedulability of a transaction. They can 
also affect the manner in which a physical terminal reacts to entry of a 
transaction type. 


Application programs are declared in separate but related macro 
instructions. However, the application program designated to process a 
particular transaction code is really just another transaction 
attribute. The process through which a completely received input 
transaction is united with its associated application program is called 
"message scheduling." The variable attributes associated with the 
transaction code, the number and relative importance of other 
transaction codes, the number of received but not processed messages, 
the intent of associated application programs toward the data to he 
processed, the amount of currently available space in control block 
storage pools and buffers -- these and other factors influence the 
process of message scheduling. The influencing factors are called the 
"message scheduling algorithn." 


Through selection of options at system definition time, through the 
design and use of data bases, specification of buffer sizes, and, most 
directly, through the declaration and selection of transaction 
code-related options, the IMS/VS system designer can influence the 
scheduling algorithm. Depending upon the breadth of his understanding 
of the algorithm, he can enhance the performance of the system by 
manipulating the algorithm to meet his requirements. 


The remainder of this section on message scheduling considers the 
scheduling algorithm in these topics: 


e Message class and region class 

e Load balancing 

e Selection priorities 

e Processing limits 

e Application program output limits 
e Multiple and single segment messages 
e Multiple and single message mode 
e Response mode 

e Non-update transaction processing 
e Conversational attribute 

e Data base processing intent 


® Processing intent propagation 


Design and Control of a DB/DC Systen 2.9 


e Application program abnormal termination 
e Contention for resources 


e Control block buffers -~ PSB and DMB 


Message Class and Region Class 


Each message (transaction code) is assigned a class at system 
definition time. This class assignment determines into which message 
region an application program is loaded. When the IMS/VS message 
regions are started, they are assigned from one to four message classes. 
When a message region is assigned more than one class, the scheduling 
algorithm treats the first class specified as the highest priority 
class, and each succeeding class as a lower priority class. 


If more than one class is specified, the message selection process is 
handled as follows. The first class specified is scanned, in 
transaction priority sequence, for waiting messages. If there are no 
messages waiting for the first class, the second and following classes 
are also scanned in priority sequence. If there are messages waiting in 
the first class, the highest priority message is selected for 
scheduling. If, for external reasons (for exanple, program or 
transaction stopped by master terminal operator), this message is not 
schedulable, the next message of equal or lower priority in that class, 
or the highest priority message in the next class, is selected for 
scheduling. If the highest priority message in the first class is not 
schedulable for internal reasons (data base intent or no more space in 
PSB pool or DMB pool to bring in needed blocks), the scheduling option 
of the transaction indicates the type of scheduling algorithm that is 
used. The scheduling option is specified at system definition by the 
TRANSACT macro. The options are: 


1. Schedule only transactions of egual or higher priority in the 
selected class. 


2. Schedule higher priority transactions in the selected class. 
3. Schedule any transaction in the selected class. 


4. Skip to the next class and attempt to schedule the highest 
priority transaction in that class. 


Note that these scheduling options are specified for each transaction; 
therefore, each attempt to schedule a different transaction may change 
the algorithm, if the algorithms are different for transactions within 
the same class. 


Message region class assignments and transaction class assignments 
can be modified at execution time to control message throughput. 


If multiple message regions process the same message class and a data 
base processing intent conflict occurs, the highest priority 
transactions scheduled against a data base will not necessarily be 
processed before processing lower priority transactions scheduled 
against the same data base. If you desire to process all higher 
priority transactions scheduled against a data base before processing 
any lower priority transactions, no processing limit should be specified 
for the higher priority transactions, or only one message region should 
process that message class. 
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Load Balancing 


Load balancing is the facility to schedule the same application 
program and the same transaction in multiple message regions. The 
application program and the transaction are designated for parallel 
scheduling at system definition time. The application must be 
designated as a parallel scheduled application before any transaction 
processed by that application will be scheduled in multiple regions. 


When an SMB is available to be scheduled but is already scheduled in 
another region, it is checked to determine whether it can be parallel 
scheduled. The PARMLIM value of the TRANSACT macro specifies the number 
of messages that should be engqueued before another region is scheduled. 
This value is multiplied by the number of regions already scheduled for 
this transaction. If the result is less than the number of messages 
engueued, another region is scheduled for the transaction. If the 
region is unschedulable for internal reasons (data base intent), the 
next transaction within the class is scheduled. No cutoff priority will 
be set as the transaction is already scheduled within IMS/VS. 


Selection Priorities 


When more than one transaction of a given type is waiting to he 
scheduled, the specified transaction scheduling priority determines 
which transaction code is selected next. It does not determine which is 
actually scheduled. Only the tests of the transaction's readiness for 
scheduling, which occur after selection, determine if the transaction 
gueue is allocated to an application program. The selection priorities 
are useful for influencing the response time to input transactions and 
for load balancing. Two priorities can be specified. One is called the 
“normal priority"; the other, "limit priority." Related to the normal 
and limit priorities is a “linjt count." When the number of input 
messages of a specific transaction type waiting to be scheduled is equal 
to or greater than the limit count, the normal priority is reset to the 
limit priority value. 


The priority of a transaction code causes it to be selected either 
before or after other transaction codes. If there are multiple 
transaction codes at the same priority, they are selected on a 
first-in/first-out basis. However, if there are multiple transaction 
codes at the same priority and the same class, with many messages 
already enqueued for each transaction codes, the individual transaction 
codes will be selected on a first-in/first-out basis, but the different 
messages may not be selected in the same sequence in which they were 
entered. For example, A, B, and C are transaction codes with processing 
limit counts of 1. These codes are entered in the sequence ABCBACCAC. 
The sequence in which they are selected is ABCABCACC. An example of the 
typical use of selection priorities can be found under the topic 
"Message Scheduling" in the IMS/VS General Information Manual. 

Another effective way to utilize the selection priorities is to 
declare a normal priority value of zero. Zero priority is a null or 
"not eligible for scheduling" level. Messages accunulate until the 
processing limit count is reached; at this point the limit priority is 
effected and scheduling occurs. This technique is called "batching 
messages." 


The normal priority is not restored until all messages enqueued on 
the transaction code have been processed. It is possible that more 
messages will be added to the queue while the transaction is waiting or 
im process at the limit priority. Note that the priorities are 
selection priorities, not execution priorities. Once a transaction has 
been selected for scheduling, the selection priorities have no influence 
until it is again recognized to be waiting for scheduling. 
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The effectiveness of the selection priority assignments is related to 
how frequently the selection process occurs. The following section 
discusses a means of influencing this. 


Processing Limits 

Through the establishment of processing limits, the frequency with 
which scheduling selection occurs can be influenced. In the time 
between schedulings, processing iS going on in the message regions. 
Meanwhile, messages are accumulating in the message queues. As they 
accumulate, the interactive effects introduced by new message types, and 
the changing of selection priorities, are rearranging the order of 
waiting transaction codes. Conceivably, while a large gueue of messages 
is being processed, important activity assigned to a high priority 
transaction code is waiting. 


When the program processes a large queue of messages and updates data 
base segments, other application programs wishing to access an updated 
segment are placed into a wait state. The length of time that the other 
applicatioa programs have to wait depends on whether the updating 
program is processing its queue in multiple or single message mode. 


To allow controlled re-entry to the message scheduling selection 
process, a processing limit count can be specified for each transaction 
code. Each time a scheduled (processing) program requests a new 
message, the limit count is checked. When the number of requests 
exceeds the limit count, the application program is told by the control 
program that there are no more messages. In fact, there may be more. 
When the application program is told there are no more messages, it 
completes its processing and returns the transaction queue to its proper 
place among others waiting to be scheduled. If it is returned to a 
priority level where other transaction codes are waiting, it assumes an 
eligibility for selection below them, even though all have the same 
numeric priority. 


Application Program Output Limits 


By establishing program output limits during system definition, the 
IMS/VS user can influence the number and the size of the output segments 
from the application program to the message queues. When an application 
program exceeds the previously-specified limits, a status code is 
returned indicating an error. Any further attempt by the application 
program to exceed the limits results in abnormal termination. 


Abnormal terminations can be prevented by checking the number and the 
Size of application program segments. This process of checking 
eliminates IMS/VS system abnormal terminations that occur when 
application programs loop while inserting messages or segments into the 
message queues, or when they inadvertently insert segments of invalid 
lengths. 


Multiple and Single Seqment Messages 


A message, in the most general sense, is a finite sequence of 
transmitted symbols. In the context of IMS/VS, this is called a 
transmission. A transmission is terminated by a logical condition 
called end-of-data {EOD). The transmission is partitioned into 
seguences of symbols, called messages, by an end-of-message ([(EOM) 
symbol. 
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A message is partitioned into smaller sequences of symbols, called 
segments, by an end-of-segment (EOS) symbol. There are only three valid 
combinations qf the conditions represented by EOS, EOM, and EOD. They 
are: 


Condition Represents 
EOS EOS 

EOM EOS/EOM 

EOD EOS/EOM/EOD 


In the most complex case, a transmission containing several 
multisegment and single segment messages would look like this: 
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Using the simple symbols, the same transmission would be represented 
like this: 
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The assignment of values to the symbols that represent the conditions 
end-of-transmission, message, and segment is not significant to this 
discussion. However, it is significant that the conditions can he 
represented by more than one transmitted data character. Most 
key-driven terminals generate only one character per keystroke. MThus, 
it may be necessary for the terminal operator to perform more than one 
Manual operation to signify EOS or EOH. 


Por input transmission, detection of the EOM condition by IMS/VS 
indicates that a complete message has been received. A complete message 
is eligible for scheduling, and ultimately processing, by ths 
application program to which it is destined. 


At the time the first EOS condition, or the first EOS following an 
EOM, is detected, IMS/VS examines the text of the preceding segment. 
Within the extent of the segment there must appear a valid transaction 
code, predefined through use of the TRANSACT macro instruction. One of 
the attributes that can be assigned to a transaction code specifies 
whether a message is multiple or single segment. The effect of this 
specification is null if multiple segment specification is selected. If 
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Single segment specification is selected, the system equates the EOS 
condition to an EOM condition. Thus, each segment is treated as a 
complete message. 


The primary concerns when selecting the multiple or single segment 
attribute are human factors, application requirements, and physical 
terminal characteristics. For example, let us assume the following: 


e An application requires only single segment entry. 
°® Most users enter data from a key-driven terminal. 


e The terminal has an automatic character generation feature (FOS 
after pressing carriage return). 


Then, the selection of multiple segment as an attribute of a 
transaction code would require an additional keystroke to signify FOM or 
EOD. 


Another example: assume all of the preceding conditions are true 
except that the line length of the data to be entered exceeds the 
Single-line capacity of the terminal. The appropriate and more natural 
selection is multiple line. However, if the application were one with 
very high usage, the overhead of processing multiple line messages might 
be sufficient to justify adjustment of the short message buffer length. 
The operational characteristics of transaction entry would be altered. 
Using the same terminal with the special EOS generation feature 
disabled, the operator enters the first line, presses the carriage 
return, enters the remaining data on the second line, then presses the 
EOS key. The result is a single segment message. 


When the Message Format Service (MPS) is used to format input, the 
relationship between the segments described above and the actual message 
segment created by MFS is user-defined. 


When MFS is used to edit input, the end of input for a given message 
is signalled by: 


e EOM or EOD 
e Completion of processing for all defined DFLDs 


At the end of input for a message, MFS presents the completed message 
segments to the DC component of IMS/VS; this component looks for a 
destination name. If the destination is a transaction defined as a 
Single segment and more than one segment has been created by MFS, an 
error message is sent to the input terminal. 


For more information on MFS, see the section in this chapter called 
"Message Format Service." 


Consuit the IMSZVS Operator 


ah ual for more information 
about the various t?rminals suppor ° 


MOLTIPLE AND SINGLE MESSAGE MODE 


The message mode attribute of a transaction code is used to notify 
the system of the manner in which an application program views the 
transactions it processes. Single mode indicates that each message is 
processed independently of all other messages that are read. Multiple 
mode indicates that all the messages of this transaction code, read 
during a given scheduling of the application progran, are to be 
considered as related to one another. For example, the application 
program accumulates control totals that are written out only at program 
termination. It does not affect the message selection criteria of the 
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scheduling algorithm. It does, however, affect the amount of main 
storage required by program isolation, message processing throughput, 
and, potentially, the integrity of the data bases used by user programs. 
If multiple mode is selected, there is potential for greater throughput. 
Multiple mode results in fewer system-generated I/O operations, and less 
system time per message, when more than one message is processed per 
application program scheduling. However, all data base resources 
modified in any way by the user remain enqueued until user program 
termination. 


If more than one message is processed per scheduling of a user 
program, large storage requirements for IMS/VS program isolation could 
result. If program isolation enqueue chains become very long, 
throughput is adversely affected. Also, if a program must be terminated 
and rolled back by IMS/VS to break a data base deadlock situation, the 
backout and reprocess time is increased in proportion to the number of 
messages processed. In addition, very long backout chains in the 
Dynamic Log may require extra I/O operations and increase the 
possibility of exceeding the capacity of the data set. If this happens, 
application activity is quiesced. 


Internally, the difference in single and multiple mode transaction 
processing is related to the frequency at which pending data hbase 
buffers are written. In single mode, all pending data base buffers are 
written each time a new message is requested by the application progran. 
These operations are performed regardless of the value assigned as a 
processing limit count. Multiple mode defers buffer write until the 
application program terminates, unless a CHKP call was issued by the 
application program. A CHKP call causes all buffers modified by the 
user to be written at the time the call is issued. 


An additional consideration is imposed for program isolation. When 
the transaction code causes data base updates, the enqueue of the 
updated segments is held until the point at which the program can be 
restarted without having to reprocess those updates. In Single mode, 
this point is reached each time a new message is requested by the 
application program. Multiple mode defers reaching this point until the 
application program terminates. This causes more segments to be 
engueued, and the engueued segments to be held longer. Other programs 
needing access to the enqueued segments are delayed, and the chance of 
deadlock is increased. Since message response is also held, and not 
sent to its destination until the same point is reached, the choice of 
multiple mode processing can significantly increase terminal response 
time. For information on the use of the checkpoint call (CHKP) in 


Programming Reference Manual. 


Response Node 


Response mode describes a connection between IMS/VS and a 
communication line or terminal that can occur only for certain terminal 
types under condition specified during IMS/VS system definition. When 
response mode is in effect, IMS/VS will not accept any input from the 
communication line or terminal until it has sent the output response to 
the previous input. 


Response mode is in effect from the time the last segment of a 
transaction has been received by IMS/VS until the application progran 
inserts a response to the response PCB, which is usually the I/O PCB. 
When more than one message is inserted using the response PCB, response 
mode is reset when the first message using the response PCB is 
transmitted. Any remaining messages issued by the application progran 
are treated as non-response application program output. If the 
application program does not produce a response, the terminal remains in 
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response mode and master terminal intervention is required to restore 
proper terminal operation. 


The terminal types that can be defined [TERMINAL or TYPE macro) to J 
Operate in response mode are the: 1050, 2740, 2741, CPT-TWX, 3270, 3600, 

3767, 3770, and 3790. The 3790 is forced to operate in response mode. 
The others may be defined as: "forced" -- always operating in response 
mode, "negated" -- never operating in response mode or “transaction 
dependent” -- operating in response mode only when a transaction defined 
by the TRANSACT macro as a response mode transaction is entered. 


Response mode for the 1050, 2740, 2741, and CPT-TWX terminals stops 
all operations on the communication line and is referred to specifically 
as “line response mode." Response mode for the 3270, 3600, 3767, and 
3790 stops all operations on the terminal and is referred to 
specifically as "terminal response mode." 


The specification of terminal response mode and no automatic page 
delete (NPGDEL) is not recommended for the following reasons: 


e NPGDEL causes the current output message not to be degqueued at the 
time of input. 


e Terminal response mode causes input to be inhibited until the 
current output message has been dequeued. 


The combination of these specifications may require master terminal 
intervention to reset the terminal response mode. 


Design Considerations: Before response mode definitions are specified 


for terminals and transaction codes, consider the following: 


e On a switched line, response mode enforces synchronization terminal 


operation. ) 


e In response mode, terminal operators can only enter one transaction 
at a time and must wait for a reply before entering another 
transaction. 


® For a terminal defined as “transaction dependent," transaction that 
are not defined as response mode transactions permit entry of 
additional input without waiting for a reply from the previous 
transaction. 


® Master terminal intervention is required when an application progran 
fails to respond to a transaction from a terminal in reponse mode. 


e In some environments, specifying "forced" response mode for some 
terminal types may result in fewer line operations and improved 
performance. 

e For some terminal types (2740 without Station Control Feature, 2741, 
and CPT-TWX), a specification of response mode prevents the operator 
from having to enter a null message to receive the response to the 
last input. 

For BTAM or VTAM terminals don't use the following specifications: 
® The combined specification of FORCRESP and NPGDEL. 


e The combined specification of TRANRESP and NPGDFL if 
MSGTYPE=RESPONSE is specified for the TRANSACT macro. 


The first specification is not recommended because NPGDEL prevents the ) 
current output message from being dequeued at the time of input; the 
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second specification prevents the terminal response from being reset 
until the current output message is dequeued. 


Further information on terminal operations using response mode is 
contained in IMS/VS Operator's Reference Manual, and IMS/VS Installation 


Guide. aa a Sa 2822¥5 taste 


For 3600 and 3790 support, see the section "Terminal Response Node" 
Function for Communication manual. For SLU type P support, see the 
section "Terminal Response Mode" in the chapter "Type P Secondary 
Logical Unit Programmer's Guide" in the same manual. For MFS support, 
see the section "Type, Terminal, and Config Macros" in the chapter 
"“IMS/VS System Definition Considerations" in the IMS/VS Message Format 


aap ae ome ni 


A transaction code which does not cause an update to a data base can 
be so defined to the system. This allows a program that handles 
multiple transaction codes, and only updates the data base for a subset 
of these transactions, to be scheduled concurrently with other update 
programs when it is to process a transaction that does not cause an 
update. 


Transactions must be defined as non-update transactions when entered 
from non-error-checked terminals supported by IMS/VS. They are also 
non-update for entry by switched terminals that are signed on for 
INQUIRY purposes. 


When a transaction is defined as non-update, the associated 
application program is prevented from updating the data base. This is 
the case even though the processing option in the PSB specifies update 
capability. 


Conversational Attribute 


Scratch pad areas {[SPAs) are work areas through which an application 
program and a terminal establish a quasi-interactive relationship called 
a conversation. That is, continuity is established with the terminal 
Operator, by the application, across multiple message entry and response 
sequences. The conversation can be suspended, reinstated, or 
terminated, by the terminal operator, through the command language. A 
conversation is normally terminated by the application, not the terminal 
operator. 


The system maintains scratch pad areas on a direct access data set or 
in main storage. Residency is specifiable by transaction code. The 
choice of main storage or direct access residency influences the 
response time for transactions that have the conversational attribute. 


Although the system can operate with one maximum size main storage 
SPA, or one direct access SPA, then only one conversation can be in 
process at a time. If a high percentage of transaction processing is 
conversational, a similar number of SPAs should be specified in the 
system definition SPAREA macro statement. If a conversational 
transaction code is entered, and all SPAs are in use, that transaction 
is rejected by the system. An insufficient number of available SPAs 
could result in terminal user dissatisfaction. 


If a transaction code has the conversational attribute, it can have 


effects on overall system performance. The choice of main storage 
versus direct access residency affects not only system performance, but 
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also the response characteristics of the conversational transaction. 
The following discussion elaborates on the potential effects of buffer 
fragmentation and the relative throughput and response characteristics 
of conversational transactions. 


Main storage resident SPAs, and read/write space for direct access 
resident SPAs, are acquired from the Communication Work Area (CWAP) 
buffer pool when a conversation is initiated by entry of a 
conversational transaction code. Main storage is retained throughout 
subsequent exchanges between the terminal and destination applications. 
It is released upon termination of the conversation. Since the main 
storage SPA buffer space is retained over a relatively long period of 
time, its potential ability to fragment the buffer pool is relatively 
high. Fragmentation of the CWAP buffer pool can cause processing delays 
in terminal I/O service and in the initiation of other conversations. 
However, since the SPA is both main storage resident and dedicated for 
the life of the conversation, response and throughput are significantly 
improved. The size of the CWAP buffer pool is specified during systen 
definition with the GENERAL keyword of the BUFPOOLS macro. For more 
information on the BUFPOOLS macro GENERAL keyword parameter, see the 


If the SPA is on direct access, space is initially acquired from the 
buffer pool at the same time as for a main storage resident SPA. 
However, it is retained only long enough to write to direct access. SPA 
buffer space is freed. Space is re-acquired when the application 
program returns the SPA, and is freed as soon as the SPA is rewritten to 
a direct access device, The use of direct access SPAs decreases the 
possibility of extended delays introduced by buffer fragmentation. 
However, because buffer requests are made during the time an application 
is active in the message processing region, any delay due to lack of 
buffer space directly affects throughput. In addition, since the 
application must wait for the SPA to be written out, overall processing 
time for each transaction is increased and response time extended. 


To enhance performance for conversational processing, conversational 
transactions can be defined with fixed-length SPAs. For such 
transactions, the main storage SPA uses only the fixed length that was 
defined. For direct access resident SPAs, tha defined maximum length is 
always used, however, performance is increased on program-to~progran 
Switches because the direct access SPA is not updated. 


Fixed-length SPAs defined during conversation initialization must 
remain in effect for the duration of that conversation. For 
conversations whose first transaction codes defined fixed-length SPAs, 
all successive transactions used as destination applications in the same 
conversation must also be defined with fixed-length SPAs of the same 
length. If not, a status code indicating an error is sent to the 
calling appiication. If the Multiple Systems Coupling feature is used 
and conversations will run in a system that is not the input terminal 
system, fixed length SPAS must be used. For more information about the 
Multiple Systems Coupling feature, see Chapter 5 of this publication. 


An additional performance enhancement for conversational processing 
is the automatic compaction of all SPAs for queuing and logging. All 
blanks and X'CO's are eliminated for queuing and logging, and the 
application program receives the unpacked SPA. 


Data Base Processing Intent 

A factor that can significantly increase the overhead of the 
scheduling process is the intent of an application toward the data bases 
it uses. Intent is determined by examining the intent list associated 
with the PSB to be scheduled. At initial selection, this process 
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involves bringing the intent list into the control region. The location 
of the intent list is maintained in the PSB directory. If the analysis 
of the intent list indicates a conflict in data base usage with a 
currently scheduled transaction, the scheduling process must select 
another transaction code and try again. 


There are several intent levels that can be stated for a given 
segment type. The list 
for the PSB Generation utility program, and the code that is used 
decision tables that follow: 


stated 
in the 


R = 


below shows the level of intent, how it may be 


No sensitivity -- segment type not referenced. 


Express read-only -- segment type referenced -- PROCOPT=GO0. 


Note: See "Processing Intent Specifications" in this chapter 
for an explanation of the various processing options (PROCOPTs). 


Retrieve segment 


type referenced -- PROCOPT=G or Kk. 


Update -- segment type referenced -- PROCOPT=A, I, R, or D 
or segment type has propagated intent. 


Exclusive use -- 


If exclusive use 
not be scheduled 
sensitive to the 


segment type referenced -- PROCOPT=E. 


is specified for a program, that program will 
concurrently with any other program that is 
same segment types. 


The following decision table shows which programs can be scheduled 


concurrently. 
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X Indicates Conflicting Actions When Transaction 
Scheduling Is Attempted 


Since exclusive intent does not allow a program to be scheduled while 
programs sensitive to those segments are operating, no dynamic 
serialization is done via ta2 enyguéeue/dequeue facility, 
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Conflicting actions occur only if the same segment type is declared 
"Exclusive Use" by at least one of two programs intending to reference 
the segment type. 


A PSB that contains a PCB for a SHISAM segment that has delete 
sensitivity will be scheduled exclusively. This is because the method 
used by IMS/VS to ensure program isolation cannot be used for SHISAM 
deletes. Since there is no delete flag, a VSAM erase must be done to 
delete the sagment, and since IMS/VS uses relative byte addresses as the 
identification of a segment, there is no way to prevent another user 
from inserting a segment with the same key prior to the time the program 
which did the delete reaches a sync point. 


A PSB that contains a PCB for an HSAM data base will always be 
scheduled exclusively against these data base segment types. Unless the 
PSB for the program being scheduled is currently resident in the PSB 
buffer pool, determining schedulability involves a direct access I/0 
Operation. 


Exclusive intent may be required for long running BMP programs that 
do not issue checkpoint call because of the excessively large size of 
the enqueue/dequeue table. 


An exception to the use of the enqueue/dequeue facility to provide 
program isolation is accomplished by the use of the PROCOPT=GO option; 
this allows programs to access segments without an enqueue being done 
for those segments. When this occurs, a program can retrieve segments 
which have been altered or modified by programs which are still active 
and while the changes are subject to being backed out. See the IMS/VS 


option. 


Processing Intent Specjfications 


With Program Isolation, the only processing intent that affects the 
schedulability of IMS/VS programs is exclusive intent. 


The processing option parameter [PROCOPT) of the PCB and SENSEG 
statements of a PSB generation determines the processing intent an 
application program kas on data. The scheduling options are: 


G Get function. 


I = Insert function. 

R = Replace function. 

D = Delete function. 

A = All, includes the previous four functions. 

E = Used in conjunction with the previous five functions, and 
specifies that an application program has exclusive use of 
the data base or segment specified. 


K = Indicates key sensitivity only. 


Scheduling Intent Types: There are three scheduling intents used to 
determine the schedulability of an application program: read only, 
update, and exclusive intent. If a segment has more than one intent 
type as the result of multiple references or intent propagation, the 
most restrictive use is set. Intent types are associated with the 


aforementioned processing intent specifications in the following manner: 
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e Read Only Intent 


For schedulability without Program Isolation (PI) operative, read 
only intent allows the program to be scheduled with any other number 
of read only users and one update intent program. This intent is 
set for any segment that specified PROCOPT=G or PROCOPT=K on the 
associated SENSEG statement. In addition, this intent is propagated 
to all segments that are reguired to obtain the information 
necessary to satisfy a DL/I call. Fer example, a logical child 
segment is requested ina call, and the logical parent's key was 
specified as “VIRTUAL.” All segments that must be retrieved to 
construct the logical parent's concatenated key have read only 
intent set. The extent of propagation is discussed below. 


e Update Intent 


When PI is operative, update intent is treated as read only intent 
for scheduling purposes. 


When PI is inoperative, update intent allows any number of programs 
that reference the same segment types for read only to be scheduled 
With the updating program. All programs that reference the same 
segment type for update intent must be scheduled serially. 


This intent is set if the associated SENSEG statement specified 
PROCOPT=I, R, or De. Update intent is set for the associated segment 
regardless of any key sensitivity specification, either explicitly 
Or implicitly specified. This intent can be propagated to other 
segments in this data base or related data bases. The amount of 
propagation is determined by the processing options specified, the 
data base organization, the pointer combinations used, and the SEGM 
statement RULES options chosen at physical DBDGEN time. The 
implications and extent of intent propagation are discussed below. 


e Exclusive Intent 


Exclusive intent prohibits the concurrent scheduling of any programs 
that reference the same segment type as the program that has 
specified exclusive use. Intent propagation must be considered when 
exclusive intent is used. Intent propagation is discussed below. 


This intent is set if the associated SENSEG statement specified 
PROCOPT=E and the segment does not have key sensitivity. Key 
sensitivity can be specified on the associated SENSEG statement, 
using the KEY/DATA option of the SOURCE operand in a logical DBD, or 
by omitting the specification of the complete concatenated segment 
in a logical DBD. This occurs when you specify the logical child 
segment and not the logical or physical parent in the concatenated 
segment definition. There is no propagation of the = option. Note 
that the specification of both PROCOPT=E and K on a SENSEG statement 
causes the exclusive (FE) option to be ignored. 


Implications and Extent of Intent Propagation: As discussed earlier in 
this section, the implications of intent propagation depend on many 
factors. Some of these factors are physical organization, pointer 
combinations, processing options, segment rules, and logical 
relationships. The following paragraphs explain their effect on 
scheduling concurrency as they relate to typical data base structures. 
Each processing option is discussed in a separate section. Keep in mind 
the fact that if a segment has more than one processing intent type (as 
the result of explicit or implicit processing options) the most 
restrictive intent is used. 
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e Get Processing Option 


A segment using PROCOPT=G or K causes read only intent to be set for 
that segment. In addition, read only intent is propagated to all - 
segments that are used to complete a GET type call. Sensitivity to 

a logical child segment implies sensitivity to its associated 
logical or physical parent. In either case, read only intent is 
propagated to the associated parent segment, and all its parent 
segments, ina direct line upward to the root segment. 


Replace Processing Option 

A segment using PROCOPT=R causes update intent to be set for that 
segment. If the segment is part of a concatenated segment 
definition, and the logical parent/physical parent part of the 
concatenation can be replaced, it has update intent propagated to 
it. No other propagation of intent occurs. 

Insert Processing Option 


Insert intent propagation is based on two basic rules. These rules 


do not apply if Program Isolation is operative. 


1. Programs that separately insert a physical parent segment and its 
physical child are not scheduled concurrently. If the program 
inserting the physical child terminates first, and if IMS/VS 
abnormally terminates before the program inserting the physical 
parent terminates, the physical parent segment is backed out of 
the data base by /ERESTART processing, leaving a dangling 
physical child segment. 


2. Programs that insert child/logical parent concatenated segments 
involving the same logical parent are not scheduled concurrently. 
If the insert rule of the Logical parent is either virtual or - 
logical. The physical insert rule prohibits inserting the logical 
parent by means of a concatenated segment. Only the logical 
child need be inserted. 


Update intent is set for the segment type designated by PROCOPT=I in 


the SENSEG statement of the PCB, or for all the segments designated by 
SENSEG statements when the PROCOPT=I is coded in the PCB statement (rule 


1). 


Update intent is propagated to all the immediate children {down one 


level) from the designated segment because of rule 2. If the designated 
segment is a logical child, the update intent is propagated to the 
logical parent segment as specified by rule 3, and to the immediate 
children of the logical parent as specified by rule 2. If the insert 
rule of the logical parent is physical, then one program per logical 
child segment type can be concurrently scheduled. 


The first variable that affects insert intent is the data base 


organization. Since segments in a HISAM data base are hierarchically 
related by physical juxtaposition, a segment insert can cause other 
segments in the data base record to shift physical location. However, 
since a data base record can reside in several separate data set groups, 
only the data set group containing the inserted segment type is 
affected. The rule is: all segments residing in the same HISAM data set 
group as the segment type to be inserted have update intent propagated 
to then. 


The second variable that affects insert intent is the pointer 


combinations specified for segments residing in HD type data basa 

organizations. When physical child pointers are selected to address the 

designated segment, the physical parent has a different pointer for each | 
of its children that concurrent programs maintain separately. However, ) 
if the choice is hierarchical pointers to address the designated 
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segment, the physical parent addresses all of its children by a single 
hierarchical pointer chain. Concurrent update programs for the 
different physical children, therefore, violate rule 1. When the 
immediate physical parent segment has hierarchical pointers, the data 
structure is scanned in an upward direction until a parent segment is 
found that uses physical child pointers, or until a root segment is 
encountered. The immediately previous physical child segment of the 
parent segment so located, and all dependent segment types of that 
immediate physical child segment, have update intent propagated to then. 


e Delete Processing Option 


The propagation of update intent from segments designated with 
PROCOPT=D is based on the physical child's dependence on the 
physical parent. If the physical parent is deleted, its physical 
children must also be deleted. Therefore, beginning at the 
designated segment type, update intent is propagated to all its 
physical dependent segment types and to their physical dependents, 
down to the lowest level of the data structure. When a segment that 
is a logical child is encountered in the downward scan, its logical 
parent's delete rule is determined. If the rule is virtual, update 
intent is propagated to the logical parent and its physical 
dependents. When a segment type that is a logical parent is 
encountered in the downward scan, the delete rules of its logical 
children and their physical parents are determined. 


If the delete rule is virtual and/or bi-directional virtual, then 
update intent is propagated to the logicai child and to its physical 
dependents, and/or to the physical parent and its physical dependents. 
Since the propagation is downward, all segments in the downward scan are 
inspected for logical relationships. As they are encountered, the 
logical child/logical parent/physical parent segment types are processed 
in the same manner as the original segment type. Deletion of the parent 
requires deletion of all physical dependents. 


When the immediate physical parent of the designated segment has 
hierarchical pointers, the data structure is scanned in an upward 
direction until a parent segment is found that is a root segment, or a 
parent segment is found that is pointed to by physical child pointers. 
That segment type found, along with all its dependent segment types, 
have update intent propagated to then. 


Application Program Abnormal Termination 


Upon abnormal termination of a message or batch-message processing 
application program, internal commands are issued to prevent 
rescheduling. These commands are the equivalent of /STOP. They prevent 
continued use of the program and the transaction code in process at the 
time of abnormal termination. The master terminal operator can restart 
either or both stopped resources. At the time abnormal termination 
occurs, a message is issued to the master terminal and to the input 
terminal that identifies the application program, transaction code, and 
input terminal. It also contains the system and user completion codes. 
In addition, the first segment of the input transaction, in process by 
the application at abnormal termination, is displayed on the master 
terminal. 


The stop action is performed automatically. Even though a message is 
issued, its occurrence could go unnoticed by the master terminal 
operator. Such a failure, involving a major application that serves 
many transaction codes, could have adverse effects on system 
performance. 
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The potential effects of commands entered from any terminal, that 
cause unavailability of scheduling resources, are severe. Operators 
should be instructed to display system status frequently. If a program 
that terminated abnormally inserted any message segments, they are 
transmitted, although the message may not be logically complete. 


Program isolation dynamically backs out data base updates, and 
cancels message output made by application programs that terminate 
abnormally. To avoid the adverse effect that this backout can have on 
programs concurrently processing in the system, data base segments that 
have been changed are enqueued using the IMS/VS enqueue/dequeue routine. 
This routine ensures that no other programs can access the changed data 
base segments until either the application program that requested the 
change completes successfully, or terminates abnormally; and until all 
changed segments are restored to their original states. 


Program isolation ensures that a dynamic log (IMSVS.DBLLOG) is 
maintained. The dynamic log is a sequential data set, on direct access 
storage, written with OSAM to facilitate following chains through it. 
All the log records created because of a given user program are 
back-chained, with the chain anchor in the PST to which the program is 
attached. The chain pointer is the block number and the offset within 
the block. When a synchronization point is reached, or if the program 
terminates successfully, the anchor in the PST is reset to zero. If the 
program terminates with an abnormal termination, the data base changes 
are backed out to the last synchronization point specified by the MODE 
parameter of the scheduled transaction code. If it is a hatch-message 
processing program that does not reference a transaction code, or whose 
transaction specified MODE=MULT, it is backed out to its schedule point, 
or to the last checkpoint, whichever is most recent. The hackout is 
accomplished by passing the data base log records, that were dynamically 
logged and chained, from the PST to the data base backout module. 


A synchronization point is defined as the point at which an 
application program can be restarted. 
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All output messages inserted by an application program, with the 
exception of messages inserted to alternate PCBs that have been 
designated to have the Express Message feature, are enqueued to a 
temporary destination associated with the PST. The Express Message 
feature is a PSB Generation option for an alternate PCB. It specifies 
that messages sent to this PCB are not to be backed out if the 
application program terminates abnormally. When the application progran 
successfully reaches a synchronization point, the program's output 
messages are transferred from their temporary destinations to their 
final destinations. If the application program abnormally terminates, 
all messages enqueued to temporary destinations are deleted and 
cancelled. Those messages inserted to the alternate PCBs that have the 
Express Message feature were never enqueued to the temporary destination 
and cannot be cancelled. 


Program Isolation provides a call function (ROLL) through which an 
application program can remove the effect of its processing. Issuance 
of this call function abnormally terminates the application program task 
with an indicative completion code. Voluntary abnormal termination 
uSing this call function does not cause the program and transaction to 
be stopped, nor does it produce a storage dump. 


One other kind of application program abnormal termination is 
possible. Since data base updates are isolated by the program isolation 
enqueue/dequeue facility, the possibility of a deadlock can arise. 
Deadlocks can be avoided by selecting one of the deadlocked programs for 
abnormal termination, with a special code that causes the program's data 
base updates and unsent message output to be backed out. The 
transaction input that was being processed by the program is retained, 
and the program is rescheduled. 


The program to be abnormally terminated and rescheduled in a deadlock 
Situation is selected using the following algorithn: 


Both the waiting program that completes the deadlock circuit and the 
calling program whose request will cause a deadlock are evaluated 
according to the table below. Their corresponding values are compared. 
The program with the smallest value is selected for termination. In 
case of a tie, the time stamp taken at sync-point is the tie breaker. 
For wait-for-input programs (including Fast Path message-driven 
programs) the time stamp taken at message GU time is used. This action 
prevents time spent on the wait-for-input queue from biasing the 
tie-breaker computation in favor of a wait-for-input program that is not 
heavily utilized. A time stamp is also taken at program schedule time 
to indicate the implied syne point at program start. 
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! 1. BMP mode=mult or no SMB input ! 6 { 
} 2. Fast Path non-message-driven program { 6 ! 
| 3. Fast Path online utility program | 6 | 
| 4. BMP mode=sngl | 4 ' 
! 5. MPP mode=mult that did not deadlock in the | | 
} previous scheduling | 3 | 
1 6. MPP mode=mult that was abnormally terminated | ! 
| for deadlocking in the previous scheduling | 2 | 
| 7. MPP mode=sngl that did not deadlock in the | | 
] previous scheduling | 1 { 
1 8. MPP mode=sngl that was abnormally terminated | ! 
| for deadlocking in the previous scheduling | 0 | 
| 9. Fast Path message-driven program | 0 ' 
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Whenever the resource that the calling program is requesting has 
multiple owners {for example, several owners in share mode), the calling 
program is abended. No other factor enters into the decision process. 
) 


Whenever more than two programs deadlock, only the calling program 
and the program completing the deadlock circuit are involved in the 
selection process as to which is to be abended. The program completing 
the deadlock is the program that the caller has to wait for to obtain 
the reguested resource. 


In IMS/VS installations running under OS/VS1, after any abnormal 
termination in an MPP {for example, application program abnormal 
termination, program isolation deadlock, or ROLL call), the MPP may not 
be able to reclaim all the storage used by the application for future 
scheduling. A system abend may eventually occur because of insufficient 
storage and the MPP will be terminated by IMS/VS, after two consecutive 
GETMAIN failures are detected, to release unusable storage in the 
region. 


Control Block Buffer Pools -- PSB and DMB 

Control block pools are maintained in the IMS/VS control region for 
program specification blocks (PSB) and data management blocks (DMB). 
Each buffer pool must be at least as large as the largest control block 
it will contain, plus the next successively larger block, for each 
additional processing region concurrently active. 


The IMSVS.ACBLIB data set must contain control blocks for all 
application programs (PSBs) and all data bases (DMBs) referenced by the 
application programs. When an application program is to be scheduled, 
the PSB and DMB pools are examined to determine which control blocks 
must be brought into main storage. If all required blocks are resident, ) 
the program is scheduled. If required control blocks are not resident, - 
the applicable pool is searched for space to hold the block. If space 
is found, the block is loaded and the program is scheduled. If the pool 
does not contain the required free space, the blocks currently resident 
are examined to determine which unused blocks can be removed. When the 
selection process is complete, any open data bases referenced by the 
unused blocks are closed, and the space is released for use by the new 
control blocks. The new control blocks are then loaded, and the 
application program is scheduled. 


Excessive loading of control blocks can have a severe impact on 
performance. If possible, the DMB pool should contain enough space to 
hold all DMBs used with online data bases. This reduces the number of 
OS/VS opens and closes, and their impact on system performance. 


DATA BASES 

System definition requires that data bases to be used in the DB/DC 
system configuration be identified. The positive declaration of data 
base names enables the system to limit the domain of the online control 
program to only some specific subset of all installation data bases. 
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If data base data sets, Fast Path DEDB area data sets, or the DC 
Monitor data set (if residing on a tape device) are specified with JCL 
statements included in the control region procedure, these data sets are 
initially allocated at control region startup. Using the dynamic 
allocation macro [DFPSMDA), the user can specify data bases to be 
dynamically allocated when needed, and deallocated when no longer being 
used. See the chapter, “Dynamic Allocation Interface Macro (DFSMDA)," 


to code and use this macro. 


Data base data sets and Fast Path DEDB areas can be dynamically 
allocated explicitly with the /START command, or implicitly through the 
DL/I OPEN command and deallocated with the /DBR command. The DC Monitor 
data set can be dynamically allocated at the time it is started with the 
/TRACE ON command and deallocated when stopped by the /TRACE OFF 
command. 


All data base data sets considered for dynamic allocation must he 
cataloged except DC Monitor data sets which must not be cataloged. A 
data set initially allocated with JCL can be dynamically deallocated and 


reallocated during the execution of the control region. 


Figure 2-1 illustrates the creation of a parameter list to be used to 
dynamically allocate and deallocate IMS/VS data bases. The IMS/VS user 
prepares DFSMDA macro statements which are assembled in a normal OS/VS 
problem program job. The DFSMDA macro is placed in IMSVS.MACLIB during 
IMS/VS system definition. The assembler output is link~edited into 
IMSVS.RESLIB, and will be loaded from there when needed, 


A job control language procedure, named IMSDALOC, is placed in the 
IMSVS.PROCLIB data set by IMS/VS system definition for subsequent use in 
generating the parameter list(s). This procedure is described in the 
chapter “The IMS/VS Procedure Library" in the IMS/VS System Programming 
Reference Manual. 


OS/VS 
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Figure 2-1. Dynamic Allocation Parameter List 
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STARTING AND STOPPING THE IMSZVS CONTROL REGION 

A normal shutdown of IMS/VS is initiated by the master terminal 
operator entering a /CHECKPOINT command. The /CHECKPOINT command shuts 
down IMS/VS in an orderly fashion. Following a checkpoint shutdown, the 
master terminal operator can start IMS/VS and enter the /NRESTART 
command for a normal restart of IMS/VS. If IMS/VS was not terminated 
with an orderly shutdown, the /ERESTART command must be entered to 
emergency restart IMS/VS. 


The log tape, the restart data set, and the dynamic log are closed by 
the STAE routine when IMS/VS fails. If the log tape cannot be closed, 
the master terminal operator must use the OS/VS DUMP command or execute 
a stand-alone dump to create a dump data set containing main storage. 
This dump data set will be used with the log tape to close the systen 
log when IMS/VS is emergency restarted. Because the log tape can be 
closed during the emergency restart if it was not closed during an 
IMS/VS failure, the IMS/VS system log terminator utility (DFSFLOTO) is 
optional. 


IMS/VS restarts can be performed from either the restart data set or 
the log tape. The restart data set is a direct access storage device 
(DASD) data set that contains the control blocks necessary for a normal 
restart or emergency restart of IMS/VS. With the restart data set, the 
master terminal operator can choose between restarting from DASD or 
restarting from the log tape. Even when the restart is from tape, the 
restart data set is used because it contains the checkpoint and log tape 
serial number information necessary for the restart. If the restart 
data set is unavailable, the serial numbers and checkpoint must be 
entered with the emergency restart or normal restart command. 


The log tape must always be mounted when IMS/VS is running because it 
is used for restarting IMS/VS, collecting statistical information, and 
recovering data bases. A normal restart of IMS/VS only requires that 
the new log tape be mounted when IMS/VS is restarted. With an emergency 
restart of IMS/VS, the old log tape can be mounted in order to be closed 
by IMS/VS. After the old log tape is closed, a request for a new log 
tape will be issued; after the new log tape is mounted, IMS/VS will 
continue with the restart until completion. 


If OS/VS fails, a restart from tape will be required. Other 
conditions requiring a restart from tape are when the message queues 
need to be rebuilt or reformatted, or the log tape or IMS/VS system data 
sets are not closed by IMS/VS. The master terminal operator can choose 
to do a tape restart by entering the serial number of the last mounted 
log tape with the normal or emergency restart command. The tapes 
required for restarting are determined by IMS/VS. 


Automatic restart is an option that can be used if it was defined 
during system definition. With automatic restart, the master terminal 
operator starts IMS/VS but does not initially specify the type of 
restart. Automatic restart determines the format of the restart and 
sends a message to the master terminal operator stating that the restart 
is in progress. If the restart data set is not available, the master 
terminal operator is asked to enter /NRESTART or /ERESTART depending on 
the type of restart required. 


IMS/VS supports dual logging of system log tapes. Dual logging is 
the duplicating of information on two log tapes while IMS/VS is running. 
The purpose of dual logging is to ensure that a readable log tape is 
available for restart processing. During a restart from tape, IMS/VS 
will automatically switch between the primary log tape and the secondary 
log tape whenever an I/O error on missing record is encountered. For 
more information on closing and recovering the system log, see the 
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section "Restoring Integrity of the IMS/VS System Log," in the IMS/VS 
OQperator’s Reference Manual. 


BATCH CHECKPOINT/RESTART 

The batch checkpoint facility provides batch-message programs with 
the means of synchronizing checkpoints taken of their environment with 
the IMS/VS log tape. It also enhances the integrity of data bases 
updated by batch-message programs, by allowing the restart facility to 
back out data base changes being made by such programs at the time of a 
system failure. If a batch-message processing program abnormally 
terminatess, program isolation ensures that backout procedures occur 
automatically. The data to be backed out is the data base change 
records logged since the last synchronization point created by a CHKP 
call. The time lag is significantly less using program isolation with 
batch checkpoint/restart, than if the data base had to he stopped and 
taken offline for batch backout. 


The batch checkpoint facility is implemented by the use of the IMS/VS 
checkpoint (CHKP) system service call from the application program. 
This call is used to indicate a synchronization point at which data base 
updates can be restarted. The actual checkpointing of the batch progran 
environment, and the routine used to restart it, are at the option of 
the user. If OS/VS checkpoint is to be used, the user must request, as 
part of the DL/I CHKP call, that the system take the checkpoint. 


Note: The checkpoint ID table, as referenced below, is used to 
coordinate the checkpoints on the IMS/VS system log with the activity of 
any batch-message regions, for the purpose of emergency restart. This 
table also contains the ID and serial number of the last startup or 
shutdown checkpoint. 


For batch-message programs (not message-driven): 


A non-message driven BMP program functions like a batch progran, but 
receives data base service like an MPP. No identifiable (explicit) 
synchronization point exists until the program issues the CHKP call. 


1. Optionally, an OS/VS checkpoint of the user's region is taken. 
2. Altered data base buffers are written. 


3. The checkpoint ID, supplied in the CHKP call, is written to the 
log tape. 


4. The checkpoint-ID table is updated, for use in subsequent 
emergency restarts. 


5. The dynamic log is updated by releasing all change records prior 
to the current synchronization point. 


For batch-message programs (message-driven): 


BMP programs that access the message queue via the I/O PCB, havea 
defined (implicit) synchronization point established by the MODE= 
parameter in the TRANSACT macro. To IMS/VS, the BMP program looks like 
an MPP. If MODE=MULT is selected, end-of-job is the natural 
synchronization point. BMP programs can issue the CHKP call to cause an 
explicit synchronization point, and define a point from which restart 
can be performed. Care must be taken to ensure that the dynamic log 
buffers do not become full because the CHKP calls are too infrequent. 
All output messages, that are not destined to express alternate PCBs, 
are held until a synchronization point occurs. All input messages since 
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the last CHKP are reprocessable. The following general events occur in 
this type of BMP: 


1. Optionally, an OS/VS checkpoint of the user's region is taken. 
2. Altered data base buffers are written. 


3. The checkpoint ID, supplied in the CHKP call, is written to the 
log tape. 


4. The checkpoint-ID table is updated, for use in subsequent 
emergency restarts. 


5. The dynamic log change records for the calling BMP are released. 


6. Output messages to all TP PCBs are sent, and input messages are 
dequeued. 


7. AGU to the I/O PCB is internally generated for the application 
program. 


If MCDE=SNGL is specified on the TRANSACT macro instruction, a 
natural synchronization point exists at each GU on the I/O PCB. 
Functions similar to those above are performed by IMS/VS; however, the 
user does not have to execute a CHKP call because the GU causes the 
necessary synchronization points. 


Instead of the OS/VS Checkpoint/Restart option, the user can specify 
the IMS/VS Extended Checkpoint/Restart facility. This consists of a 
restart call (function code XRST) and optional parameters on the CHKP 
call. If used, the XRST call is the first call to IMS/VS issued by the 
user program. If a restart is not in progress, the XRST call is 
effectively a NOP. 


The issuance of an XRST call causes the following action to he taken 
for subsequent CHKP calls issued by the program: 


1. Optionally, user specified areas, that is, application variables, 
control tables, and position information for non-IMS/VS data 
sets, are recorded on the IMS/VS log. 


2.2 The fully qualified key of the last record processed by the 
program on each IMS/VS data base is recorded on the log. 


3. The functions of the standard CHKP call are performed, except 
that the OS/VS checkpoint of the user's region is not taken. The 
user has the option of using OS/VS Checkpoint/Restart, the IMS/VS 
restart (XRST call), or neither, but not both. 


Por message processing programs: 


The CHKP call functions exactly as a message GU for a single mode 
program, allowing a program operating in multiple mode to control the 
spacing of its synchronization points. 


In the case of a checkpoint FREEZE or DUMPQ shutdown, IMS/VS waits 
for any batch-message programs that are processing to issue a CHKP call, 
before proceeding with the shutdown. This action makes it possible to 
identify the point at which the batch-message program should be 
restarted. 


In the case of a PURGE shutdown, IMS/VS waits for batch-message 
programs to terminate before proceeding with the shutdown. 
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The log record containing the checkpoint ID is used by emergency 
restart as follows: 


Using the checkpoint-ID table, emergency restart determines, and 
identifies to the operator, the point on the log where restart 
processing is to begin in order to back out incomplete updates made 
by the message and batch-message programs processing at the time of 
the system failure, It initiates restart processing from that point. 
If backout is successful, the CHKP ID from which each BMP can be 
restarted is identified to the operator. 


Transactions, partially processed by message processing programs at 
the time of system failure, that caused data base modifications, have 
their associated data base modifications backed out by emergency 
restart. 


The IMS/VS user must determine the means of checkpointing and 
restarting his batch and batch-message processing programs. He may use 
the OS/VS checkpoint/restart facility, or create one of his own. 


If the DL/I user chooses to write his own checkpoint/restart 
routines, he must, as a minimum: 


e Record application variables and control tables. 

e Record position information for non-IMS/VS data sets. 

e Provide a restart entry point and reinitialization procedure. 

e Properly initialize IMS/VS control blocks; for example, PXPARMS. 


Use of the XRST call and user area parameters on the CHKP call 
simplifies the task for the user writing his own restart routines. 


e A restart situation is indicated by specifying a checkpoint ID in 
the parm field on the execute card in the JCL or in the XRST call 
itself. 


e Normal entry point and initialization procedures are used. 
e User areas recorded at checkpoint time are restored. 


e A GET UNIQUE is issued for each GSAM data hase for the last used 
record if the data base was open at the time the checkpoint was 
taken. 


e No data is returned as the result of the GU, but status codes are 
saved in the user PCBs. 


e If the data base was opened for output, then a PNT function code, 
reguesting POINT, is used. 


e GSAM data bases are automatically repositioned at restart if the 
XRST call is used. 


* The checkpoint ID is returned to the user program to allow it to 
link to its own restart subroutine. 


In the case of batch-message programs, an actual checkpoint/restart 
routine may not be required. If the program is truly driven by the 
message queues, IMS/VS repositions the gueues to the point where a CHKP 
call was issued. The user need only start the batch-message program 
normally. 
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Even though most batch-message programs require some re-programming 
to accommodate the CHKP function, the increased data base integrity and 
availability should justify the effort. 


Since the IMS/VS control region waits until all batch-message regions 
issue CHKP calls before proceeding with a shutdown checkpoint, a 
batch-nessage program with few or no CHKP calls can delay or prevent 
system shutdown. The /STOP REGION command with ABDUMP can he used to 
force the abnormal termination of such a region. However, it is 
recommended that the user add CHKP calls to batch-message programs, 
particularly if a FREEZE or DUMPQ checkpoint is to be requested. If a 
PURGE shutdown is used, re-programming is suggested for batch-nessage 
programs that run for a long time, because IMS/VS waits for these 
programs to terminate before proceeding with the shutdown. 


The IMS/VS control program provides the ability to queue messages 
received on direct access storage and in main storage. Messages can be 
received from communication terminals or application programs and can be 
destined for communication terminals or application programs. A message 
destined for an application program is called a transaction and begins 
with a transaction code. All transactions of the same type [same code) 
are queued in a serial chain based upon time of receipt by IMS/VS. A 
serial queue exists for each defined transaction code. All messages 
destined for a particular communications logical terminal are queued 
serially like transactions. A serial queue exists for each defined 
logical terminal (Figure 2-2). 
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Figure 2-2. General Message Queue Structure 


MESSAGE QUEUES AND MESSAGE SELECTION 


The serial queue for each defined logical terminal consists of an 
incore queue, four prioritized queues, and a nonprioritized queue. In 
descending priority sequence, the levels are as follows: 


Q00 
This is the incore queue. All messages in this queus are sent 
immediately and are not written to the direct access message 
queue data set. Messages on this queue are not considered 
recoverable and will be discarded if an error occurs during 
transmission. 

001 
Reply to response type messages. This queue is used for response 
mode conditions when a terminal is in terminal or line response 
mode or conversational mode. This queue can contain only a 
Single message. 

Q02 
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Replies to a transaction from a terminal in exclusive mode. 
Output to a terminal in exclusive mode will be queued to 902. If 
a response mode condition exists, the output will be placed in 
Q01 instead of Q02. 


003 
System messages which are to be enqueued. This includes 
broadcast text, output from the /DISPLAY command, and all DFS 
messages with the exception of the DFS555 ahnormal termination 
messages. The DFS555 message will be placed on other +han Q03 to 
notify the terminal of the abend (for example, a terminal in 
response mode will receive the DFS555 abend message from Q01). 


Q04 
All other traffic. This queue is used for application 
programming output, message switches, alternate PCB output, etc. 


905 
Backup message. This gueue is used: 


e To resend messages from terminals with the resend feature. 


e For conversational processing, the last response to the terminal is 
kept for purposes of the /HOLD and /RELEASE commands. This queue is 
not prioritized and is transparent to the user. 


The following are the possible modes of a terminal. The terminal is 
not restricted to a single mode but may be in more than one mode at the 
same time. 


e CONVERSATION -- A terminal is in conversation mode from the time it 
enters a conversational transaction until the time the conversation 
is completed or abnormally terminated. A conversation is normally 
terminated when the message has been sent and dequeued and the 
application program has cleared the transaction code field in the 
scratchpad area (SPA). A conversation can terminate abnormally in 
several ways: 


1. An application program ABENDed. 

2. The IMS/VS operator issues an /EXIT command, a /START NODE 
command, a /START LINE command with no PTERM keyword, or an /IAM 
DONE command with an INQUIRY LTERM (switch line disconnect). 

3. When there is an inconsistent definition between systems. 

e EXCLUSIVE -- A terminal is placed in exclusive mode when the 
/EXCLUSIVE command is issued. Exclusive mode is terminated by an 
7END command, a /START LINE command, a /START LINE PTERM command, a 
/START NODE command, or a /IAM command. 

@e RESPONSE MODE -- System definition specifications determine when a 
terminal will be placed in response mode. Terminal response mode is 
terminated in several ways: 

1. When the message has been sent and dequeued. 


2. The IMS/VS operator issues a /START LINE PTERM command, or a 
/RSTART LINE PTERM command. 


3. An IMS/VS restart. 
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Line response mode is terminated in several ways: 
1. When the initial attempt to send the message has been made. 


2. The IMS/VS operator issues a /START LINE command, a /RSTART LINE 
command. 


3e An IMS/VS restart. If the Fast Path feature is used, terminal 
response mode will automatically be re-entered on an IMS/VS 
restart or after the issuance of an /RSTART LINE PTERKM™ command if 
a message is in the output buffer. 


e LOCK -~- The locked mode prevents the sending and receiving of 
messages to a terminal. A terminal, NODE, or a logical terminal 
(LTERM) can be placed in locked mode when the operator issues a 
/LOCK command. This mode is reset by the /UNLOCK command or the 
/IAM command. 


e TEST -- Test mode ensures that any input message entered into a 
terminal is transmitted back to the terminal with error analysis 
procedures bypassed. A PTERM or NODE is placed in test mode by the 
/TEST command. Test mode is reset by an /END command, a /START 
command, or /IAM command. 


e LOOPTEST -- The looptest mode provides for the establishment of an 
output write loop whereby a user-entered message is continuously 
transmitted to the terminal. A PTERM is placed in looptest mode by 
the /LOOPTEST command. Looptest is reset by an /END command, a 
/START command, a /RSTART LINE command, or an /IAM command. 


e QERROR -- A logical terminal will be placed in a stopped state if an 
I/O error is encountered while attempting to read a message from or 
write a message to a message queue. This condition is reset when 
the operator issues the /START command. 


e STOP -- The stopped state prevents the selection of any output 
quened on a logical terminal associated with a physical terminal. 


For terminal using VTAM, the /STOP NODE results in the termination 
of the session between IMS and the node. This termination occurs 
immediately for most devices but only at the end of the message for 
3270 devices and SLU type 2 devices. The /STOP NODE command also 
prevents logon until a /START command or /RSTART command has been 
issued. 


The /STOP command, the /PSTOP command, and the /MONITOR command also 
cause a terminal to enter the stopped state. This state is reset by 
issuance of the /START command or the /RSTART command. 


e SNA guiesce -- When IMS/VS is sending output messages to a VTAM 
programmable node and the node wishes to suspend reception, the node 
will signal IMS/VS to halt transmissions after an end-of-chain has 
been sent. See the section "VTAM Signal Commands" in IMS/VS 


quiesce-at-end-of-chain function. 


e INOP -- The physical terminal is marked inoperable by IMS/VS device 
Support whenever a physical error is detected. All logical 
terminals associated with this physical terminal are marked not 
eligible for selection for message transmission. The /START command 
Or the /RSTART command will reset the inoperable condition. 
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e COMPINOP -- Component inoperative (not ready) can be set in two 
ways: 


1. An error is detected that can be isolated to a component of a 
terminal. 


2. By the issuance of the /COMPT command or the /RCOMPT command for 
terminals defined to VTAM. All logical terminals associated with 
this component are marked ineligible for selection for message 
output. Component inoperative is reset when the operator issues 
a /START LINE PTERM command, a /START NODE command, another 
/COMPT command, or a /RCOMPT command. Special signals from the 
device, such as device end from a 3270 device, or special 
commands from a 2270 device can also cause the resetting of the 
component inoperative or not ready state. For unique device 
considerations see the chapter "IMS/VS Telecommunication Device 
Support" in the IMS/VS Operator's Reference Manual. 

® PAGE, SCREEN, and COMPONENT PROTECTION -- This is a state supported 
for video terminals and SLU type p devices. Logical terminals 
associated with this physical terminal are ineligible for selection. 

For a discussion on screen protection for the 3270 devices, see the 

Operator's Reference Manual, and the chapter "Message Formatting 

Fuactions" in the IMS/VS Message Format Service User's Guide. For 

programmable VTAM devices, see the section "Display Screen 

Protection for Stations Defined as 3601" in the chapter "“IMS/VS 

Support for Advanced Function" and the section “Extended Output 

Component Protection" in the chapter “Type P Secondary Logical Unit 

Programmer's Guide™ in the IMS/VS Advanced Function for 

Communications. 


DETERMINING MESSAGS SELECTION 


The following figures allow you to determine which messages will be 
selected for transmission to a terminal when IMS examines the message 
queues for a message to send. 


© STEP 1: 


Find, in Figure 2-3, the source of the message in question and note 
the queue the message is in. 


® STEP 2: 


Referring to Figure 2-4, find the state of the logical/physical 
terminal or node. Note the queue levels from which messages will be 
selected when the terminal is eligible for selection. If the 
message is in one of these levels, IMS will attempt to send the 
message. Otherwise, the message will remain in the queue for later 
transmission. 


Example: To find what happens to a /FORMAT command entered from a 
terminal in conversation mode: 


1. Find the source of the message in Figure 2-3. The /FORMAT is 
entry I.A.11. Since the terminal is not in exclusive mode, the 
/FORMAT response will be placed in Q03. 


2. Find the terminal state in Figure 2-4. Conversation is state 12. 
Queue levels selected are Q00 and Q01. Since the /FORMAT 
response was in Q03, it will not be sent until the conversation 
is terminated. 
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Source of Message 


Queue Level 
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I. Control Region 


A. IMS/VS Code 


1. Error messages to a terminal created while 
processing input from or output to a terminal 
messages such as DFS064 NO SUCH 
TRANSACTION CODE, DFSO65 TRAN/LTERM STOPPED, etc.). 


10. 


(for example, 
The same error messages as above but detected 
in a remote MSC system: 


- The input message that was discarded because 
of the error put the terminal in response 


mode. 


- The terminal is in exclusive mode. 
- None of the above. 


Direct responses to terminal requests 
(for example, messages such as DFS290I NO MESSAGE 
AVAILABLE FOR OUTPUT). 


Terminal connect, disconnected, 
(for example, DFS2002 TERMINAL CONNECTED, 
DFSO53 TERMINAL RESTARTED-~PLEASE REFORMAT SCREEN). 


Messages directed to the master terminal 
(for example, DFS253I TCU INOPERABLE LINE x 


PTERM y). 


TEST or LOOPTEST messages. 
DFSO58 command completed. 


Output from the /DISPLAY, 


commands, 


7YSTART, /RSTART, /STOP, /PSTOP command status 
These messages wiil be discarded if 

the MSGDEL=SYSINFO or the MSGDEL=NONIOPCB parameter 
was coded in the TERMINAL macro statement. 


messages. 


Broadcast text. 


or restarted 


/RDISPLAY OUTPUT 


These messages will be discarded 
if the MSGDEL=NONIOPCB parameter was coded in the 
TERMINAL macro statement. 
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Q00* 


Q01** 


Q02 


Q03 


Q00* 


Q00 


Q03 


Q00 


000* 


Q03* 


003 


Q03 


* For the 2770, local reader, and 2780, these messages are put in 003 


on a last-in first-out basis. 


** If the terminal 1s removed from response mode before this message 
is completely sent, the message will be moved to Q02 if the terminal is 


in exclusive mode or to QO4 for all other conditions. 


Figure 2-3 (Part 1 of 3). 


Source of Messages 
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Source of Message Queue Level 


11. IMS/VS commands (for example, /FORMAT, /TRACE, etc.). 


B. 


- Terminal in exclusive mode. Q02 
- Terminal not in exclusive mode. 003 
User Exit Routines 


1. Request to cancel message via return code -- Q00* 
an IMS/VS message iS generated. 


2. Request to cancel message and send a message Q00* 
from the user's message table. 


3. Message ‘echoed’ back to terminal using the MFS O01 
segment exit. 


Message Switch [terminal to terminal). This message Q04 
will be discarded if the MSGDEL=NONIOPCB parameter 
is coded in the TERMINAL macro statement. 


II. Dependent Region 


A. 


I/O PCB or Response Alternate PCR** 


1. Conversational mode. Q01 


* For the 2770, local reader, and 2780, these messages are put in 003 
on a last-in first-out basis. 


** Response Alternate PCB restrictions: 


Vs 


Figure 


Conversational -- The destination must be the same physical 
terminal. If not, an AY status cod2 will result if processing in 
a local system; or a conversational abend will result if 
processing in a remote MSC system and if the error was detected 
at the terminal-attached systen. 


If the current input message put the terminal in response mode, 
the destination must be the same physical terminal. If not, an 
A9 status code will result if processing in a local system. This 
is not checked if processing in a remote MSC systen. 


Output to both a response alternate PCB and the I/O PCB is not 
allowed. If the terminal is not in conversational mode, output 
to multiple response alternate PCBs is allowed. 


Destination logical terminals must not have more than one 
physical terminal assigned for input purposes. An AY status code 
will result if processing in a local system. This is not checked 
if processing in a remote MSC systen. 

An ISRT call prior to a GU DL/I call is not allowed to the I/0 
PCB. 
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Source of Message Queue Level 


oe 2. The input message being processed put the Qo 1* 
terminal in response mode. 


3. Terminal in exclusive mode but not in response Q02 
or conversational mode. 


4%. None of the above. Q04 
B. Alternate PCB 
1. If the /TRACE command was issued for the Q04 
destination PTERM and the message ID was deleted, 
a 6701 log record with an ID=ICLR is created. This 
message is discarded if the MSGDEL=NONIOPCB parameter 
parameter was coded on the TERMINAL macro statement. 


C. IMS DFS555 Abend Message 


1. The input message being processed put the Qo1* 
terminal in response node. 

2e The terminal was in exclusive mode. Q02 

3. None of the above. 004 


* If the terminal is removed from response mode before this message 
is completely sent, the message will be moved to Q02 if the terminal is 
in exclusive mode or to Q04 for all other conditions. 


we Figure 2-3 (Part 3 of 3). Source of Messages 


Design and Control of a DB/DC System 2.39 


State Queue Level Selected 
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1. PTERM inoperative Q00 
2. Component inoperative Q09 
3. PTERM in test mode 900 
4. SNA gquiesce-at-end-of-chain received Q00 
5. Qerror Q00 
6. Line STOPPED, PSTOPPED, or MONITORED Q00,003* 
7. Node stopped, before termination Q00 


of session, node disconnected due to 
/CLSDT or LOSTERM, or IMS shutdown 


8. PTERM STOPPED, PSTOPPED, or MONITORED Q00,003% 

9. LTERM STOPPED or PSTOPPED Q00,003* 

10. PTERM locked Q00,003* 

11.  LIERM locked 000 ,003* 

12. Conversational node 900,001 

13. Response mode 000,001 

14, Exclusive mode Q00,001,002 

15. None of the above Q00,001,9002,003,004 


* Messages for Q03 are selected if: 
- The line or terminal is not in response mode. 
- An active conversation is not in process. 


- The terminal is not in exclusive mode. 


Figure 2-4. Queue Selection - 


The IMS/VS control program utilizes three OSAM data sets for direct 
access queue storage. All queue data sets have the same block size, 
which is specified by the IMS/VS user at system definition time. 


Figure 2-5 illustrates the relationship between the three queue data 
sets. 
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Figure 2-5. Queue Data Set Relationships 


OPERATION OF QUEUES 


All messages received are assigned OSAM relative record numbers. 
However, they are not written immediately to the queue data sets. If no 
Space is available in the main storage buffers, the buffer which has 
been referenced the least is written to its queue data set, and the 
space in main storage is assigned to the new message. If a message 
still exists in main storage when it is dispatched to its destination 
(input to a program or output to a terminal or another program), no 
reference to the direct access data sets is required. All messages are 
logged by the IMS/VS control program to provide message queue 
recoverability in case of failure of either the IMS/VS or host operating 
system control programs. 


Messages received are represented by either single or nultiple 
segments. The amount of space required to contain a message determines 
the size of the records to which it is allocated. When the transaction 
or logical terminal queue is known, the average message size is also 
used to determine the record to be allocated. The lines of text are 
placed in a variable-blocked format within a record. 


The IMS/VS message queue data sets must be preformatted before 
initial usage. The use of preformatted queues provides increased 
reliability. Reliability is increased with the preformatted data sets 
becaus the count field of the direct access device record X is not 
relied upon to write record X+1. Preformatting is performed upon 
request during restart procedures. The need to reformat the message 
queues arises only if an input/output error occurs within a queue data 
set. A write error does not result in the inability to write subsequent 
records in the data set as is the case with unformatted queue data sets. 
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Approximately 1.5 seconds is required to format each 2314 cylinder in an 
IMS/VS message gueue data set and .8 seconds for each 3330 cylinder. 


In order to provide for message queue recoverability if the queue 
data sets are destroyed, the IMS/VS control program logs: 


e all input and output message text 


e the queue pointers to each message queue chain, whenever a message 
is enqueued onto or dequeued from the chain 


If a system failure occurs and the message queue data sets are 
retained intact, the restart facilities of IMS/VS can reposition the 
queues by use of the engqueue/degueue pointers which were logged. If the 
queue data sets are destroyed, the restart facilities of IMS/VS can he 
employed to rebuild the queues from the log entries of message text. 


EMERGENCY RESTART QUEUE REPOSITIONING 


In an emergency restart situation, the message queues are 
repositioned as follows: 


e SNGL mode processing 


The message being processed at the time of the failure is the first 
message processed after the restart. 


e MULT mode processing 


All messages read by the program are processed at the time of the 
failure are returned to the queue. The first message processed 
after the restart is the first message read after the program's most 
recent CHKP call or scheduling. 


MESSAGE QUEUE REUSE 


Message queue records reside in fixed-length blocks with a block size 
common to all three data sets. The first record in each data set is a 
bit map which controls the assignment of the next n records (n = 8 * 
LRECL-1). Records in each data set are assigned from low to high by 
testing the bit map for the first bit which is on. When a bit is found 
on, it is turned off to indicate that the corresponding has been 
assigned. When a record contains a message that has been completely 
processed at its destination (has been dequeued and will not be required 
in restarting the system), the bit corresponding to the record is turned 
on. This makes the record available for reuse, 


For details on message queue data set space allocation, refer to the 


A physical terminal is the actual hardware device attached to the 
computer. The types of terminals supported include typewriters, CRTs 
(cathode ray tubes), paper tape readers, card readers, high-speed 
printers, and remote computers. The IMS/VS terminal configuration is 
defined to IMS/VS during system definition. 
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Ne 


DEVICES SUPPORTED 


IMS/VS supports: 


e IBM 
e IBM 
e IBM 
e IBM 
e IBM 
e IBM 
e IBM 
e IBM 
°e IBM 
e IBM 
° IBM 
e IBM 
e IBM 
e IBM 
e IBM 
2° IBM 


e IBM 


1050 
2260 
2265 
2740 
2741 
2770 
2780 
2980 
3270 
3600 
3639 
3767 
3770 
3740 
3790 
5110 
7770 


Data Communication System 

Display Station, Models 1 and 2 
Display Station, Model 1 
Communication Terminal Models 1 and 2 
Communication Terminal 

Data Communication Systen 

Data Transmission Terminal 

General Banking Terminals, Models 1, 2, and 4 
Information Display Systen 

Finance Communication System 

Plant Communication System 
Communication Terminal 

Data Communication Systen 

Data Entry System, Models 2 and 4 
Communication Systen 

Computer 


Audio Response Unit, Model 3 with a Touch-Tone* (or 


equivalent) telephone or IBM 2721 Portable Audio Terminal 


* IBM 
© IBM 
e IBM 
e IBM 


e IBM 


Series 1 Systen 


Systemn/3 Model 10 


Systen/7 


System 32 and 34 


Communicating Magnetic Card/Selectric Typewriter (CMC/ST) 


e Card reader/printer devices 


e 33/35 Teletypewriter (ASR) 


IMS/VS supports various communication/attachment modes for the above 
terminals. The major distinction is whether the attachment is local 
(through a channel) or remote {over telephone lines). Remote 
attachments are further broken down into two categories: switched and 
nonswitched (or leased). Switched communication lines permit the 
attachment of only one remote station or terminal at a time to a line, 
and require that the terminal operator use a data set, which is attached 
to the remote terminal, to dial up the main computer to establish 
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* Registered Trademark of the American Telephone §& Telegraph Co. 
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connection. Nonswitched communication lines are leased; that is, they 
are dedicated to use by the terminals physically attached to them A 
nonswitched line may be either a contention or polled line. Contention 
Or polled refers to the line discipline used to communicate with the 
terminal. Only one contention-type terminal may exist on a line, while 
one or more can share a polled line concurrently. A polled line with 
more than one terminal is called a multipoint line. 


See the IMS/VS General Information Manual for a description of the 
communications modes supported by IMS/VS for each physical terminal and 
for lists of the required and optional features for each supported 
terminal, control unit, and CPU. 


BTAM DATA SET LINE GROUPS 

The LINEGRP macro is used to describe each BTAM data set line group. 

The terminal(s) defined for any one LINEGRP must be of the same type 
(communication mode, polling techniques, transmission code). This means 
that a separate line group must be used for each of the following 
terminal configurations (when used): 


1050 switched 

1050 nonswitched with poll 

1050 nonswitched with autopoll 

2260/2265 remote and 2260 local mode, nonswitched 
2740 switched with transmit control 

2740 nonswitched contention 

2740 nonswitched polled 


2740 
2741 
2741 
2770 
2780 
2780 
2780 
2780 
2780 
2780 
2980 
3270 
3270 
3270 
3270 
3270 
3270 
3630 
3740 
7770 
Syste 


polled with 
switched* 
nonswitched 
nonswitched 
nonswitched 
nonswitched 
nonswitched 
nonswitched 
nonswitched 
nonswitched 
nonswitched 
local 


autopoll 
EBCDIC and nonswitched correspondence 


polled 

polled ASCII 

polled 6-bit transcode 
contention EBCDIC 
contantion ASCII 
contention 6-bit transcode 


local printer 
polled remote 


polled remote 


switched 
switched 
switched 
switched 
switched 
n/ 3 


ASCII 


(ASCIT) 


Systenm/7 nonswitched contention 

System/7 nonswitched polled 

System/7 nonswitched polled with autopoll 

Local card reader 

Local output device (printer, punch, tape, DASD) 
Spool SYSOUT 

33/35 switched 


*For 2741 switched, transmission codes for any one line group do not 
have to be of the same type. 


For further definition of a BTAM data set line group, refer to OS/VS 
BIAM, GC27-6980. At least one communication line must exist within each 
line group. At least one physical terminal must exist for each 
communication line. 
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TERMINALS ATTACHEL THROUGH VTAN 


Terminals attached through VIAM are defined according to terminal 
type by using the TYFE gracre. Valid terminal types are: 3270 local, 
3270 remote, 3601, 3614, 27€7, 377C, and 3790. 


PHYSICAL TERMINAL NETWORK DESIGN 


Selection of terminal types should be based on what function is 
expected, the locaticn and frersonnel using the equipment, and the speed 
or volume of data whick tke térgzinals are expected to handle. 


Inguiry and ccnversational capabilities are best suited to typewriter 
Or graphic type devices, the graphic devices being faster, while the 
typewriter gives a hard ccry cf the transaction. 


Batches of input can best be handled by cards or paper tape, with the 
2770, 2780, or 3770 being used for high volume and the 1050 for low. 


The printer-type terminals are best suited for applications where the 
shop floor requires infcrmaticn frcem the ccmputer but has no need to 
supply any in return. Again, the 2770 or 2780 is best suited fcr high 
volume, with the others handling less volume. 


Once the types of terminals reguired for the job are determined, the 
methcd of ccnnecting them to the computer must be considered. 


If many terminal locations are required with minimal volume, a 
switched network should be ccnsidered. This allows the use of standard 
telephone lines. The terminal operator dials the computer when he 
wishes to make an entry. One drawback to this approach is the 
possibility cf busy lines, which may cause the operator to place a call 
several times. Another disadvantage is that voice-grade lines are more 
susceptible to malfunction than leased lines. This might require the 
Operator to reguest entry mcre than one time to allow the computer to 
read it error-free. Unchecked terminals (2741, 33/35, and 7770) can 
cause input and output tc Fe lcst due to line errors which are 
transparent to the IMS/VS systen. 


When high volume is required or the terminal must be connected to the 
computer for long pericds cf time, a leased line may be more practical. 
This type of line is generally more error-free, can handle higher vclune 
of data, and requires no creratcr action to connect to the computer. If 
the leased line is chosen, the next step is to determine how many 
terminals are to te ccnnected tc this line. If several unbuffered 
terminals are connected to the line, significant delay may occur in the 
response to a terminal. It is therefore reccmmended that unbuffered 
terminals be attached alone to a line. Another consideration may be the 
need to cluster séveral terzinals in one location. The expense of 
running several telephone lines to the same location may be prohibitive. 
If so, buffered terminals shculd be considered. Their slightly higher 
cost may be more than offset by the need to run only one line, thus 
reducing the contenticn fcr line time, as the data is transferred to a 
buffer at operatcr speed and then sent across the line at machine speed. 


Most terminals suppcrted by IMS,VS are polled. For some terminals, 
consideration should also ke given to the type of polling to ke used: 
programmed or autcpoll. fFcr eHwall networks, programmed polling may 
prove more economical, since autopoll, except for binary synchronous 
lines, 1S an extra cost feature. However, programmed polling requires 
more CPU interruptions and, for a larger network, may use enough CPU 
time to make the cost cf autcpoll worthwhile. For each terminal in the 
system, programmed polling causes a hardware interrupt approximately 
every second. Autopell causes this interruption only when the cperator 
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has initiated some action on the terminal, which will generally he 
several minutes. 


Lines can ke collected by terminal type into line groups. Each new 
line group requires gwain stcrage for ccntrol blocks used by IMS/VS and 
the operating system. All lines for a particular type of terminal can 
be collected into cne line group, minimizing this storage requirement. 
However, this means that all these lines must be allocated to the systen 
at all times. When cne is removed [possibly for use by a different job 
cr system), IMS/VS does not function properly. Therefore, if cne or 
more lines are to be used by IMS/VS on a part-time basis, and it is 
desired to allocate them to cther functions at times, they should be 
organized into separate line groups. Lines may Le removed from the 
system by line grcuf. 


When binary synchronous terminals (except 3270) are used in the 
Online IMS/VS system, timeout conditions can occur when the system is so 
loaded that it cannct frecess an input line buffer and respond to the 
terminal. If the terminal operator re-enters the data before verifying 
the applicaticn program resrcnse, to determine the proper restart point 
in the data stream, this could lead to duplicate data. 


LOGICAL TERMINALS 


DEFINITION OF THE LOGICAL TERMINAL CCNCEFT 


The characteristics of terminal devices vary widely. There are 
differences in the ccntrcl mechanics, transmission code, display media, 
entry keykoards, switches, timing, and ofticnal features. Communication 
line and network characteristics further complicate and multiply the 
possikle combinations of characteristics that must be managed in the 
data communication environment. It is readily apparent that the 
applicaticn pregram shculd nct become directly involved with or 
dependent upon the characteristics of the terminal network with which it 
deals. 


By isolating the application program from its terminal network, 
economies in development cost, development time, and maintenance are 
achieved. In additicn, a certain degree of, if not complete, device 
independence is available. Applications written to a device-inderpendent 
interface may ke expanded withcut modification for the use of new 
terminal types or classes. 


At the same time, use cf device class dependent functions may be 
highly desirakle in certain aprlication areas. Control of device class 
dependent functions for an application system which serves only CRI-type 
devices could enhance the usability cf that application. 


Another requirement directly related to device independence is 
application independence. An application-supported function must be 
available from different terminal types. It is not feasible or 
practical to expect that a unique terminal be assigned to each function 
to be performed. 


For reasons of security or resource management, it may be desirable 
to associate the use of a physical terminal with its user. Whereas 
users may exist in greater numbers than physical terminals, they must be 
represented by abstractions. The primary characteristic of the abstract 
terminal is its identity. The identity is known within IMS/VS as the 
"logical terminal name" or simply as “logical terminal," 
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THE IMS/VS LOGICAL TERMINAL 


Each logical terminal within IMS,/VS has a unique set of attributes. 
A description of the attributes constitutes a partial description of the 
features available thrcugh use cf the lcgical terminal concept. 


e Current physical terminal assignment -- this characteristic may Le 
dynamically altered for reasons of terminal resource management. 
Once a signon has Leen acccaplished by ccnnecting a logical terminal 
to a physical terminal, the functions and services available are the 
same as those for a ncnswitched terminal. 


e Security authorization -- can be unique for each logical terminal in 
the system Or can represent a security level or group. 


e Next logical terminal assignment -- multiple logical terminals can 
be associated with a single physical terminal. This provides, in 
conjunction with security, the ability to uniquely identify multiple 
users of a single rhysical terminal. 


Logical terminals can be assigned to physical terminals for output 
and input purposes. When a logical terminal is assigned to a physical 
terminal for output purposes, all messages sent to that logical terminal 
are transmitted to its associated physical terminal. More than one 
logical terminal can be assigned tc a given physical terminal for output 
Furposes. Only one physical terminal can receive the output for a given 
logical terminal. The diagram belcw shows the relationship between 
physical and logical terminals for output purposes; 
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When a physical terminal is assigned to a logical terminal for input 
purposes, any message entered frcm the physical terminal is considered 
to have originated at the logical terminal. When more than one logical 
terminal is assigned tc a fhysical terminal for input purposes, a chain 
of input logical terminals is formed. Any input frem the physical 
terminal is considered tc have criginated at the first logical terminal 
on the chain. If, for scme reascn (such as security or a stopped 
logical terminal), the first logical terminal is not allowed to enter a 
message, all logical terminals cn the input chain are interrogated in 
chain sequence for their ability to enter the message. If the physical 
terminal is a 377C or a 37€7, cnly the lcgical terminals associated with 
the input compcnent are scanned. The first appropriate logical terminal 
found is considered the originator cf the message. If no appropriate 
logical terminal is found, the message is rejected with an error 
message. The diagram kelcw shcws the relationship between physical and 
logical terminals for input purposes: 
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Use of a queue for input messages received or pending output messages 
enables the application tc ke independent of time of arrival or 
transmission of messages. Association of the gqueve with the logical 
rather than the physical teruinal permits it to be moved, independent of 
the application, from device to device. Within restrictions, it permits 
a queue of messages tc Le mcved even among device classes. 


The logical terminal frevides a stable platfcrm or reference for the 
applicaticn program. Regardless of how the physical terminal network 
changes, the applicaticn remains insensitive. To the application 
program, a logical terminal can be viewed as just another sequential 
data input source cr cutfut destinaticn. 


The application program interface to the logical terminal is through 
the same call interface mechanics descrited for the DB systen. 


When 2980 terminals are defined, IMS/VS uses a logical terminal to 
define the 2972 commcn tuffer. This is an exception to the physical 
terminal/lcgical terminal relationship, in that the 2972 commen buffer 
is not a physical terminal in the conventional sense. 


LOGICAL TERMINAL NETWORK DESIGN 


Design of a logical terminal network can be as important as design of - 
a physical terminal network. It has potential impact upon syster 
security, maintainakility, and usability. Careful consideration should 
be applied from each viewpoint. 


System security administration can be hampered by not previding an 
appropriate number cf lcgical terminals through which proper terminal 
security authorization may ke applied. Too few logical terminals limits 
the number of unique security authorizations. Too many may prove 
cumbersome or ineffective in achieving security objectives. A judicious 
comkination of passwcrd and logical terminal security can reduce the 
number of logical terminals required to administer security felicy. 


Where a community of users deals with multiple applications through a 
common set of physical terminals, output volumes, schedules, priorities, 
human factors, and terminal availability are some of the more inportant 
usability factcrs tec ccensider. If pricrities require that management or 
supervision have ready access to terminals ordinarily used fcr 
operational purposes, then provision must be made for interrupting 
Operational work. A physical terminal might have two logical terminals 
ordinarily assigned -- cne fcr cperations, one for priority work. 
Authorization of the sLCCK command to the priority logical terminal 
would enatle it to stcp input and output from the operations terminal. 
Further discussicn cf the security planning for this particular case may 
be fcund under the topic "Security and Privacy" in this chapter. [It is 
mentioned here to illustrate several of the aspects of logical terminal 
network planning. The same solution to the security or pricrity aspect, 
that is, multiple lcgical terminals, can be applied if the control of 
cutput volume is a problen. 
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Where particular applications make use of device class dependent 
functions, such as curscr ccntrol, it might be useful to specify a 
separate set of logical terminals which have a relationship to that 
group of applications. Calling the application group an application 
class and the logical terminal group a logical terminal class, it is 
possible through lcgical terminal security to associate all input and 
cutput relationships with a known set of logical terminals. At the sane 
time, non-device-class sensitive transactions may be used through 
non-specific logical terminals from the same physical terminals. 
Processing applications are insensitive to the separation. The 
following example (Figure 2-€) illustrates this use of logical 
terminals: 





PHYSICAL LOGICAL 
TERMINAL TERMINALS APPLICATION 
fa ese een 
| DEVICE 
~Q r | class 
| | SENSITIVE 
an ace 
NOT DEVICE 
Y CLASS 
SENSITIVE 
Figure 2-6. Sé€parating Device Class Sensitive Terminal I/0 


To establish such a relationship requires defining two logical 
terminals for each physical terminal, then securing the transactions 
destined for application XK through logical terminals AAA and CCC. The 
common entry security for AAA and CCC cculd be referred to as a device 
class sensitive security group. All logical terminals defined for that 
purpose would then Ke secured in the same grourg. 


In certain applications it may be necessary to associate a different 
physical device for output than the one ordinarily used for infut. 
Conversely, certain physical terminal types are input-only devices. If 
output is required, a different device must be associated with this tyre 
for output. IMS,/VS system definition and ccmmands support assignment of 
cutput devices different from the input device. The allowable 
physical/logical relatiocnshirs which can be expressed are shown in 
Figure 2-7. 
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Figure 2-7. Possible Physical/Logical Terminal Relationships 


Logical Tegminal/Physical Terminal Relationship 


relationship between a terminal user, a physical terminal, a 
communication line, and a logical terminal is a diagran: 


PHYSICAL LOGICAL 


TERMINAL TERMINAL 





IMS/VS system definition describes the characteristics and 
relationship of physical terminals, communication lines, and logical 
terminals. On a nonswitched communication line, the relationship 
between a physical terminal at one end and a logical terminal within 
IMS/VS at the other is a stable relationship defined at systen 
definition time. If there is only one user of a particular physical 
terminal, typically there would be a one-to-one relationship between 
physical terminal and logical terminal. However, if a physical terminal 
is operated by multiple users, it can have many logical terminals 
associated with it. IMS/VS system definition might include a separate 
logical terminal for each user of a particular physical terminal. 


The relationship established between a physical terminal and one or 


more logical terminals at system definition can be changed through the 
command language or by a new system definition. The /ASSIGN command 
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changes logical/physical relationships dynamically. It is normally 
executable only from the master terminal. 


relationship on a switched communications network is considerably more 
complex than in the nonswitched communication line environment. IMS/VS 
System definition defines the characteristics of a physical terminal, 
communication lines, and logical terminals. However, the relationship 
between a particular physical terminal and a logical terminal is not 
established until the remote terminal user dials the System/370 computer 
to communicate with IMS/VS. The relationship between a terminal user, a 
physical terminal, a communication network, and logical terminals at 
system definition time is depicted in the following diagram: 


LINES 


PHYSICAL 


LOGICAL 
TERMINAL 


TERMINAL 





Once the remote terminal user dials in to the computer and issues the 
/IAM command to sign himself on to IMS/VS, a stable relationship between 
the physical terminal and one or more logical terminals is established. 


PHYSICAL LOGICAL 
TERMINAL TERMINAL 





In a switched communications network environment, one logical 
terminal per line is created automatically as the inquiry logical 
terminal. In addition to the physical line/terminal definition, and the 
automatic creation of the inguiry logical terminal, a pool of logical 
terminals can be defined at system definition time. When a remote 
terminal user dials into IMS/VS, an /IAM command can.be issued which 
associates logical terminals from a pool with the physical line and 
physical terminal issuing the /IAM command. 


Within any logical terminal pool for a switched communications 
network, the IMS/VS user must define one or more logical terminal 
subpools. A logical terminal subpool is composed of one or more logical 
terminals within a given logical terminal pool. A particular logical 
terminal can exist in only one pool and subpool. A remote terminal user 
can dial the IMS/VS system and sign on for a single logical terminal or 
all logical terminals within a logical terminal subpool. At system 
definition, the environment appears as indicated in the following 
diagram: 
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After a remote terminal user has dialed the Systen/370 computer 
operating under IMS/VS, several situations can exist. If the /IAM 
command is used to sign on and the LTERM parameter specifies the inquiry 
logical terminal, the following diagram applies: 
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If the /IAM command is used to sign on and the LTERM parameter 
specifies a logical terminal from the logical terminal subpool, the 
following diagram applies: 
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If the /IAM command is used to sign on and the LTERM and PTERM 
parameters are specified, all logical terminals within a subpool are 
associated with the physical terminal. 


The use of the logical terminal subpool concept allows for efficient 
use of communication facilities. All output queued on each of the 
logical terminals in the subpool for which the /IAM command was issued 
is sent to the physical terminal. 


A subpool can be defined to contain the logical terminals for all of 
the users of a single physical terminal. While a user is signed on to a 
logical terminal within the subpool, the subpool is unavailable to users 
signing on from other physical terminals. 


All inquiry logical terminal names must begin with INQU. When 
Signing on for an inquiry logical terminal, only these first four 
characters are considered significant by IMS/VS. This lets a user call 
any autoanswer line and sign on for, and use, the inquiry logical 
terminal (for inquiry transactions only), if he is aware of the INQU 
prefix. The inquiry logical terminal can only be used for non-update 
transactions, and queued output is preserved only while the user is 
signed on. So that IMS/VS can distinguish inquiry logical terminal 
names from subpool logical terminal names at the time a user signs on, 
no subpcol logical terminal name can begin with INQU. 


MASTER TERMINAL 

The master terminal is the IMS/VS control center. It must be either 
a 1050, a station-controlled 2740, a 3270, a 3767, or a 3770. If a 1050 
or 2740 is used, it must be attached through a non-switched polled 
communications line. A 3270 master terminal can be attached locally or 
through a non-switched polled line. The IMS/VS provision for a 3770 
master terminal is intended for the 3770 console component. The 
non-console components will not operate correctly if they are used as 
the master terminal. 


The master terminal operator must know all the operating aspects of 
the system. The physical location of the master terminal in relation to 
the computer console is important. If, for security reasons, they are 
not close, telephone communications should be provided. 


The details of starting the system, checkpoint, restart, and all 


commands available to the master terminal operator are in the IMS/VS 
Operator’s Reference Manual. 
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SYSTEM CONSOLE SUPPORT 


IMS/VS provides support for the OS/VS system console using the OS/VS 
write-to-operator (WTO) and write-to-operator-with-reply (WTOR) 
facilities. All functions available to the IMS/VS master terminal are 
available to the system console. The system console and master terminal 
can be used concurrently, to control the system. Usually, however, the 
system console's primary purpose is as a backup to the master terminal. 
The system console is arbitrarily defined as IMS/VS line number one. 


SYSTEMS WITH INOPERABLE MASTER TERMINAL 


IMS/VS requires a master terminal be defined for its use during 
IMS/VS system definition. Under certain conditions, however, it may be 
impractical to provide a master terminal facility; for example when the 
270X line is inoperable. In these instances, the OS/VS system console 
can be utilized to replace the IMS/VS master terminal. If desired, the 
master terminal DD statement can be omitted. If the master terminal is 
inoperable, messages will continue to be routed to it until they are 
routed to the system console or another terminal with the /ASSIGN 
command. In addition, all of the functions ordinarily performed at 
remote operational terminals can also be performed through the 
Systen/370 console. 


MESSAGE FORMAT SERVICE 

Through the Message Format Service (MFS), a comprehensive facility is 
provided for IMS/VS users of 2740, 2741, 3270, 3690, 3767, and 3770 
devices. MFS allows application programmers to deal with simple logical 
messages instead of device dependent data; this simplifies application 
development. The same application program may deal with different device 
types using a single set of editing logic while device input and output 
are varied to suit a specific device. The presentation of data on the 
device or operator input may be changed without changing the application 
program. Full paging capability is provided for display devices. Input 
messages may be created from multiple screens of data. 


A program using MFS need not be concerned with the physical 
characteristics of the device used for input and output messages unless 
it wants to use certain very specific device features. Even when these 
features are utilized, the program can request functions in a logical 
manner; no device control characters or orders may be sent directly from 
the program or may be received by the program. The presentation of data 
on the device may be changed without application program changes. Both 
logical and physical paging facilities are provided for the 3270 and 
3604 display stations; this allows the application program to write a 
large amount of data that will be divided into multiple screens for 
display on the terminal. The capability to page forward and backward to 
different screens within the message is provided for the terminal 
operator. The conceptual view of the formatting operations for messages 
originating from or going to an MFS-supported device is shown in Figure 
2-8. 
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Figure 2-8. Message Formatting Using MFS 


MrS has three major components: 
e MFS language utility 
e MFS pool manager 
e Message editor 


The MFS language utility is executed offline to generate control 
blocks and place them in a format control block data set named 
IMSVS.FORMAT. The control blocks describe the message formatting that 
is to take place during message input or output operations. They are 
generated according to a set of utility control statements specified by 
the IMS/VS system designer. There are four types of format control 
blocks: 


e Message input descriptor (MID) 
e Message output descriptor (MOD) 
e Device input format (DIF) 

e Device output format (DOF) 


The MID and MOD blocks relate to application program input and output 
message segment formats, and the DIF and DOF blocks relate to terminal 
I/O formats. The MID and DIF blocks control the formatting of input 
messages, while the MOD and DOF blocks control output message 
formatting. 


The message editor and MFS pool manager operate online during the 
normal production mode of operation. The message editor performs the 
actual message formatting operations using the control block 
specifications. The MFS pool manager controls residence in the main 
storage MFS buffer pool of the format control blocks required by the 
message editor. Efficient use of available pool space is provided by 
look-ahead fetching of required control blocks from direct access 
storage, and by maintenance of last-referenced format control block 
chains for reuse of pool space. 


Two other MFS components, a MFS service utility and a MFTEST pool 
manager are available to support optional MFS operations. 


The MFS service utility provides a method for additional control of 
the for. at control block data sets. It executes offline and can be used 
to creat2 and maintain an index of control blocks for online use by the 
MFS pool manager. 


The MFSTEST pool manager replaces the MFS pool manager to support the 


Optional MFSTEST mode of operation. The IMS/VS /TEST MFS command can be 
used to place online MFS terminals into MFSTEST mode during which new 
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applications and modifications to existing applications can be exercised 
without disrupting production activity. 


Figure 2-9 provides an overview of major MFS operations. The circled 
numbers reference notes that indicate major distinctions in MFS 
processing when the MFSTEST facility is used. The IMS/VS Message Format 
Service User's Guide provides a complete description of MFSTEST 
facility. 
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. Can execute concurrently with the IMS/VS online control region only in MFSTEST mode. 


. Replaced by IMSVS. TFORMAT in MFSTEST mode; IMSVS. FORMAT is available as secondary source of 
control blocks in MFSTEST mode. 


. The communication line buffer pool is used in MFSTEST mode. 
. Replaced by MFSTEST pool manager in MFSTEST mode. 
. Terminal operator must use /TEST MFS command to enter MFSTEST mode. 





Figure 2-9. Overview of Message Format Service 


OVERVIEW OF INS/VS 3270 SUPPORT 

The IMS/VS Message Format Service {MFS), described in the previous 
section, is used exclusively to format data transmitted between IMS/VS 
and the devices of the 3270 Information Display System. MFS provides a 
high level of device independence for the application programmers and a 
means for the application system designer to make full use of the 3270 
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device capabilities in terminal operations. The IMS/VS Message Forma 


3270 COPY FUNCTION 


When an IMS/VS system is defined to include printer components of the 
3270 Information Display System attached through a polled BSC or SDLC 
line, it is possible to allow through IMS/VS an automatic or 
operator~-controlled hard copy of the video output (or input) to be sent 
to a 3270 (3284, 3286, 3287, 3288, or 3289) printer. This hard copy can 
be requested through the use of the SCA field in the application 
program's output data, the definition of the message [see IMS/VS Message 
Format Service User's Guide), or by operator action. The hard copy 
listing is produced on an appropriate printer, which must be attached to 
the same 3270 control unit (3271/3274 or 3275/3276) as the display 
station containing the information to be copied. If a request is sent 
to a terminal that is not defined as allowing the copy function, or that 
does not support the copy function (3270 local attachment), the request 
for the copy function is ignored. 


For a complete description of terminals supporting the copy function 
see the IBM 3270 Information Display System Component Description 
Manual. 

The format of the printed output can vary from that on the display 
station as a result of blank lines [or null lines), which are ignored by 
some models of the 3284, 3286, 3287, 3288, or 3289 printers. [In all 
cases, the buffer size of the printer must be equal to or larger than 
the buffer size of the display station to be copied (3275/3284 Model 3 
has no printer buffer and this consideration does not apply). 


When printers are attached to a 3271/3274/3276 the IMS/VS systen 
definition process determines which printers are eligible to receive the 
hard-copy output of a copy operation. These printers are called 
candidate printers. When a copy operation is requested by the operator 
or an application program, the candidate printers are searched in a 
predetermined order to find a printer that can be used. The first 
printer that is not stopped, is not currently printing a message, is not 
in exclusive status, and is ready, is used. If the operator made the 
copy reguest and all printers are busy, the keyboard on the display 
station is left inoperable until a printer is available and the message 
is successfully copied to the printer. If the copy request is from an 
application program and all printers are busy, the message is not 
displayed until a printer becomes available. This prevents the operator 
from altering the data to be printed before the message is successfully 
copied to the printer. If no candidate printers are currently 
available, an appropriate error message is sent to the display station 
requesting the copy operation. If the copy operation was requested by 
the application program or the format description {DEV statement, DSCA 
operand), an attempt to send the message will be retried when the error 
message is cleared from the screen through the Message Advance Function 
(see section "3270 Information Display System" in the IMS/VS Operator's 
Reference Manual). If the copy function was requested by operator, the 
operator can ready the candidate printer(s) and retry the copy 
operation. 


Candidate printers for a particular display station result from the 
way the physical terminals are defined during IMS/VS system definition. 
Candidate printers for a display station must be defined after that 
display station but before any other display station-printer groups. 
Other display stations can intervene between a display station and its 
candidate printers, but other display station-printer sequences cannot 
intervene. For example, in Figure 2-10, PTERM 1 might be a 3275 with 
its own dedicated printer. If PTERM 2 and 3 allow the copy function, 
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then PTERMs 4 and 5 will be the candidate printers for these PTERMs. If 
PTERM 6 is allowed to use the copy function, then PTERM 7 will be the 


candidate printer for PTERM 6. 


Note that the candidate printer PTERM 7 


will not be used for copy functions from PTERMs 2 and 3, nor will 
candidate printers PTERMs 4 and 5, be used for copy functions from PTERS 
6. And, in non-VTAM environments, the copy function is not permitted 


across line, linegroup, or 3270-control-unit boundaries. 
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Figure 2-10. 
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The 3284-3 printer, when attached to a 3275, is supported by IMS/VS 


as a component of the 3275 terminal.« 


Messages are sent to the two 


components on a rotating basis, as with any component-type terminal. If 
no messages can be sent to the printer component, messages are sent 


continuously to the display component, 


just as if no printer component 


existed. If no messages can be sent to the display component, messages 
are sent to the printer as though the display component did not exist. 
As long as messages can be sent to the printer, no operator intervention 
is required. When a message is sent to the display component while 
messages are enqueued for the printer, the operator must intervene to 


allow either further display output or printer output. 


Any situation 


(such as a stopped LTERM or an inoperable printer) that prevents the 
sending of messages for the LTERM(s) assigned to a particular component 


causes message transmission to cease to that component. 
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3270 MASTER TERMINAL SUPPORT 


IMS/VS supports a 3270 terminal as a master terminal. A 3270 master 
terminal consists of two 3270 components: a 3270 display 
(3275/3277/3276/3278) and a 3270 printer (3284/3286/3287/3288/3289). 
The 3275 with an attached 3284-3 is not supported as a 3270 master 
terminal. 


When IMS/VS uses a 3270 master terminal, all messages are routed to 
the display component. Selected system-gererated messages, critical to 
IMS/VS operation, are also sent to the printer component. 


A 3270 display selected as the master terminal must have a 24-line 
80-column display screen to allow the use of the MFS master terminal 
formatting option. For additional details, see "MFS Formatting for the 
3270 or SLU Type 2 Master Terminal" in the IMS/VS Message Format Service 
Userts Guide. 


INTELLIGENT REMOTE STATION SUPPORT 

IMS/VS provides for attachment of a System/3 Model 10 and Systen/7 
using the IRSS (intelligent remote station support) interface. The 
interface provides a remote station with powerful tools to control the 
flow of data between a System/370 and terminals attached to the 
intelligent remote station. This interface provides the definition of 
transmission block formats. A primary purpose for these formats is to 
define message transmission associated with one or more terminals 
attached to the intelligent remote station. These Intelligent Remote 
Station formats are described in detail in the IMS/VS System Programming 


Conversational processing as well as presetting of destinations are 
available to terminals attached to the remote station. IMS/VS provides 
the facility of routing transaction responses to the originating source 
as well as to alternate destinations without application program 
involvement. IMS/VS provides a restart facility for the remote station 
by logging and retransmission of appropriate block and message 
identifiers. 


TRANSMISSION BLOCKS 


Two types of transmission blocks are defined in the IRSS interface. 
The data block type is used to carry message segments. The 
synchronization block type is used to carry all other required 
information such as shutdown, restart, status change, ask for output, 
and dequeue output. 


Each data block contains a block identifier containing, in four 
bytes, information that can be used by the remote station to restart its 
transmission of data to IMS/VS, if it has a restart facility. The 
content of this identifier is up to the remote station, but if the same 
identifier appears in the first data block received by IMS/VS as was 
contained in the restart message, after IMS/VS has transmitted a restart 
message, IMS/VS considers the block retransmitted and will scan for a 
restart point as described below. 


Each data segment in a data block contains a message identifier. 
This one byte messag2 identifier contains information that enables the 
remote station to identify a message or segment within a block. In 
addition, IMS/VS appends the message identifier from a segment in error, 
if an error message must be transmitted by IMS/VS to the remote station 
due to an error discovered while processing a segment. The message 
identifier is also contained in restart messages and can be used by the 
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remote station to restart its transmission of data because it indicates 
the last complete message processed by IMS/VS within the identified 
block. 


fhe message identifier is used by IMS/VS to scan for a restart point 
if a block was retransmitted after restart. IMS/VS scans the received 
block until a segment with the same message identifier as in the restart 
message, and which is flagged as the last segment, is found. IMS/VS 
then starts processing with the segments following the one found, if 
any. The entire block is discarded if no segment that meets the above 
specifications is found. Cold start messages do not contain block and 
message identifiers since none are available, but they imply binary zero 
identifiers. Therefore, the remote station should not use a block 
identifier of binary zeros in the first block transmitted to IMS/VS 
following a cold start message from IMS/VS, or the block will be 
ignored. 


A two-byte terminal identifier is used by the IRSS interface for 
destination control. The terminal identifier used in communication with 
IMS/VS must be defined when performing the IMS/VS system definition. 

The TERMINAL macro is used for this purpose. IMS/VS treats each defined 
terminal identifier as a physical terminal. Since IMS/VS has no 
knowledge about the actual physical terminals attached to a remote 
station, there is no requirement that the terminal identifier correspond 
to a physical terminal address. The number of physical terminals 
attached is also independent of the number of terminal identifiers 
specified. The terminal identifiers employed by IMS/VS IRSS provide a 
means of extending all IMS/VS facilities characteristics of a physical 
terminal to any logical destination within a station supported by IRSS. 
Since INS/VS has ho knowledge of the terminal itself, this designator 
can be used to accomplish a variety of application-dependent functions; 
for example: 


e Routing to specific terminals or devices in the remote station 


e Scheduling of specific application programs within the remote 
station 


® Batch-type terminal support similar to 2770 or 2780 terminals by 
proper definition of the remote station I/O components 


e Data collection from a variety of I/0 devices into a single stream 
identified to IMS/VS as a unigue terminal for specific IMS/VS 
application program processing 


Prior to the enqueue of a message received from a remote station, 
IMS/VS logs the identifiers pertaining to the last block and segment of 
the message. This information is also kept in the communications 
restart block (CRB) and is restored by restart. The identifiers, 
pertaining to the last message enqueued, are transmitted to the remote 
station in all types of restart messages except the cold start message. 


SYSTEM/3 AND SYSTEM/7 PROGRAM FUNCTION REQUIREMENTS 

The IMS/VS support for System/3 and System/7 does not include a 
program resident in either computer. The IMS/VS user must supply this 
program. The user's program residing in the System/3 or the Systen/7 
must be able to handle at least the following parts of the IRSS 
interface: 


e Transmission control 


® Data blocks 
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ed 


e Immediate shutdown request from IMS/VS 
e Send output complete message to IMS/VS 


It is recommended that the program be capable of recognizing error 
messages. All other information provided by IMS/VS can be used or 
ignored at the discretion of the user. 


INSZVS System Nessages 

IMS/VS system messages contain a message identification whose first 
three characters are DFS. The IRSS support extracts the number from the 
message, in case of an error message, and builds a synchronization 
block. Ail user initiated messages should be set up so they cannot be 
confused with an IMS/VS system message. 


TRANSMISSION CONTROL 


IMS/VS receives transmission blocks from a remote station in input 
mode and transmits blocks to a remote station in output mode. 


IMS/VS may request the line to do the following while in input mode: 
e Transmit error messages pertaining to received data. ~- 
e Transmit command completed messages pertaining to received commands. 


e Return a test message if a terminal has been placed in test mode 
through the /TEST command. 


e Transmit an immediate shutdown request message. 


IMS/VS causes a reverse interrupt sequence to be transmitted if any 
of the preceding conditions occur when in input mode. IMS/VS then 
accepts one additional input block after transmission of the reverse 
interrupt. An attempt to transmit more than one block results in a 
transmission error and the station is logically deactivated. 


Error messages and shutdown request messages are transmitted using 
the appropriate synchronization block. Command completed messages and 
test messages are transmitted using data blocks. 


A message transmitted by IMS/VS in output mode must be removed fron 
the queue through a request from the remote station. This is done to 
ensure that no message is removed from the IMS/VS queue until it has 
reached its final destination at the remote station. The request to 
remove a message is made using the appropriate synchronization block. 
This can be performed at any time after the last segment of the message 
has been received by the remote station but before any message is 
transmitted to IMS/VS using the same terminal identifier. IMS/VS 
retains an output message in progress on the queue if an input message 
is received for the same terminal identifier, even if the last segment 
has been transmitted but the remove request is not received. 


The remote station can transmit an error message to IMS/VS at any 
time after the first segment of the message has been received, but 
before it is removed from the gueue or retained on the queue because of 
an input message. An error message causes the logical terminal, on 
which the message is queued, to be stopped and a message sent to the 
master terminal. The message is retained on to the quene. Error 
messages are transmittted using a synchronization block. Messages 
transmitted by IMS/VS while in input mode are not queued and, therefore, 
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cannot be removed from a gueue. Consequently, the remove from queue 
message should not be sent. 


Any error detected in the interface between IMS/VS and the remote 
station results in logical deactivation of the remote station by an EOT. 


SYSTEM DEFINITION 


The System/3 and System/7 are defined using the STATION macro. 
Included in this macro are the station's polling address {if applicable) 
and the station's operating modes. 


Three operating modes may be defined in any combination: 


e Postpone type -- non-postpone type 
e Ask type -- non-ask type 
e Transmission limit -- no-transmission limit 


A System/7 station on a start/stop line has the added definition of 
output transmission code modes. The station can be defined to require 
all data blocks to be transmitted in PTTC/EBCD code, pseudo-binary 
PTTC/EBCD code, or to allow IMS/VS to determine the code. 


A station defined as postpone type is started with the postpone 
output flag set in all defined terminals. The remote CPU must send the 
resume output I/0 synchronization block to IMS/VS to receive output. 


A postpone type station has the advantage of specific terminal output 
reguests by the user program in the remote CPU. This function can 
conserve resources within that systen. 


To allow the user's program to control when to receive blocks from 
IMS/VS, the station can be definel as ask type. After the restart 
message has been transmitted by IMS/VS, IMS/VS waits to receive an ASK 
message before transmitting anything else. The ASK message is sent by a 
remote station to inform IMS/VS that the station is ready to receive. 
This message is required: 


e After IMS/VS has transmitted the NO-OUT message {I/0 synchronization 
message flag value X"'08*') to the remote station. 


e After IMS/VS has transmitted a user specified number of blocks to 
the remote station. This count is reset each time an ASK message is 
received. Messages sent following a LINE TURN AROUND requested by 
IMS/VS are not counted. 


IMS/VS transmits blocks according to normal rules after an ASK 
message has been received. When all available output that can be sent 
has been sent, IMS/VS transmits the NO-OUT I/O synchronization message. 
IMS/VS then waits to receive an ASK message before transmitting any 
further output. The transmission of the NO-OUT message can be preempted 
by reaching transmission limit. The ASK message is an I/0 
synchronization message with flag value X*10'. The NO-OUT message is an 
I/O synchronization message with flag value X'08'. The format of these 
messages is described in chapter "Communication with Intelligent Remote 
Stations" in the IMS/VS System Programming Reference Manual. 
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Transmission Limit 

IMS/VS system definition allows for the specification of a 
transmission limit for each remote station defined. The transmission 
limit is the maximum number of transmission blocks, excluding the block 
transmitted following a reverse interrupt sequence and the shutdown 
synchronization block, that IMS/VS will send in output mode between 
remote station initiated resets. The remote station uses the ASK 
message to perform this function. The ASK message is sent by a remote 
station to inform IMS/VS that the station is ready to receive. The 
transmission limit defined to IMS/VS should be the number of buffers in 
the remote station minus one, because IMS/VS may be required either to 
transmit blocks to the remote station while in input mode [see the 
description under "Transmission Control" in this chapter) or send a 
Shutdown synchronization block while in output mode. This message is 
required: 


e After IMS/VS has transmitted the NO-OUT message (I/O synchronization 
message flag value X*'08") to the remote station. 


e After IMS/VS has transmitted a user specified number of blocks to 
the remote station. This count is reset each time an ASK message is 
received. Messages sent following a LINE TURN AROUND requested by 
IMS/VS are not counted. 


The transmission limit can range from 1 to 15, or be defined as zero, 
indicating unlimited transmission. 


The three remote CPU operating modes can be defined in any 
combination. The presence (or absence) of postpone type does not impact 
IMS/VS function. IMS/VS function does vary, however, when ask type 
and/or transmission limit are specified or are not specified. 


The flowcharts below show IMS/VS function for the possible 
combinations of operating modes: 


Basic (non-ask type, no-transmission limit) 
Ask-type, no-transmission limit 

Non-ask type, transmission limit 

Ask-type, transmission limit 
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Ask type, transmission limit 
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CONSIDERATIONS UNIQUE TO SYSTEM/7 


System/7 Start/Stop Transmission Code Modes 

IMS/VS requires synchronization blocks to be transmitted using the 
pseudo-binary PTTC/EBCD transmission code. This code is described in 
the System/7 Functional Characteristics Manual, GA34-0003. 


Data blocks are transmitted using either the standard PITTC/EBCD 
transmission code or the pseudo-binary PTTC/EBCD transmission code. 
IMS/VS accepts either code on input and scans the output data to 
determine if the block contains any characters that cannot be 
transmitted using the standard PTTC/EBCD transmission code. If such 
characters are found, the block is converted to pseudo-binary PTTC/EBCD. 
Otherwise, the message is translated as standard PTTC/EBCD transmission 
code. 


IMS/VS allows the user to specify at IMS/VS system definition, ona 
per station basis, that all data blocks should be transmitted in one of 
the above transmission codes. If all data blocks are to be transmitted 
in the standard PTTC/EBCD code, all characters that cannot be 
transmitted in that code are replaced by a colon. 


The output buffer size specified by the user at IMS/VS system 
definition is doubled to allow for conversion to pseudo-binary 
PTTC/EBCD, unless the user specifies that all data blocks are to be 
transmitted using the standard PTTC/EBCD transmission code. 


Supported System/7 Start/Stop Line Types 


IMS/VS allows a System/7 to be attached on a nonswitched contention 
line or a nonswitched polled line. A polled line may be polled using 
programmed polling or autopoll. 


IMS/VS can control a polled line and therefore initiate output, if 
allowed to, at any time data transfer is not taking place without a 
potential loss of data and without Systemn/7 intervention. To try to 
avoid errors caused by loss of data on a contention line, some of the 
responsibility for keeping communication open is dependent upon the 
System/7 program. IMS/¥S issues a read when output is not available to 
send and this read must be terminated by transmission from the Systen/7. 
Since there is no indication of whether, after receiving a block, IMS/VS 
intends to transmit or return to read, unless the System/7 is defined as 
ask type, it is recommended that a System/7, attached on a contention 
line, be defined as ask type. The receipt of the cutput not available 
(NO-OUT) message informs the System/7 program that IMS/VS, immediately 
following the completion of this message, is issuing a read. 


Supported System/7 BSC Line Types 

IMS/VS allows a System/7 to be attached on a nonswitched contention 
or polled line. IMS/VS is defined as the controlling station. All 
transmissions must be in BSC EBCDIC transparent mode. 


Process Controlling Systen/7 


Since there is no facility to prevent an IMS/VS shutdown checkpoint 
while a process controlling System/7 is active, the System/7 should 
transmit a message to the IMS/VS master terminal operator, when 
communication is started, informing the operator that a process 
controlling machine is attached and that the operator should not issue a 
shutdown checkpoint until informed that the process controlling machine 
is either stopped or stoppable. 
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The flowchart below shows how IMS/VS processes a transmission block 
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CONSIDERATIONS UNIQUE TO SYSTEM/3 


IMS/VS support of the System/3 is designed to provide a high degree 
of flexibility in function but is consistent with the main storage j 
constraint inherent in smaller computers. 


While IMS/VS IRSS does not require it, it is anticipated that 
System/3 programs designed to interface with IMS/VS will take advantage 
of the ask-type station facility described under "System Definition." 
This facility allows the System/3 programmer to allocate his main 
storage resource only when he is ready to accept data from IMS/VS; thus 
alleviating the requirement for a larger, permanently-dedicated buffer 
area. 


Transmission of data in the EBCDIC transparency mode allows all types 
of data to be transmitted from an IMS/VS application program. This 
could save additional storage or programming in the System/3. 


If the System/3 is used as a subhost for locally attached terminals, 
using either the MLTA {for start-stop) or MLMP {for BSC) features of the 
System/3 Disk System Control Program, the IRSS provides each of these 
terminals direct access to an IMS/VS system with the additional 
advantage of a common I/0 interface. 


Though IMS/VS IRSS supplies a large amount of status type information 
to the Systen/3, the System/3 programmer does not need to design his 
application to process all types. Consequently he can realize a savings 
in main storage or programming within the Systenm/3. 


To fully utilize the features provided by IRSS to the System/3, the 
Systen/3 programmer should design his application to use the Disk Systen 
Control Program with the BSCA Multiline Multipoint feature. This 
support allows the user to directly control the line discipline and to , 
recognize many types of responses from IMS/VS. j 


To utilize MLMP support in the Systemn/3 to communicate with IMS/VS 
through the IRSS, the Systen/3 user should: 


1. Define two BSCA files, one for transmit and one for receive. 


2. The transmit file should be single buffered to prevent more than 
one block being transmitted after a reverse interrupt (RVI) 
indicator has been sent by IMS/VS. The reverse interrupt 
indicator must be defined and recognized for this file. 


3. It is recommended that the System/3 user utilize the get-block 
and put-block modes of the GET and PUT macros. This is 
recommended because IMS/VS IRSS data structures do not normally 
lend themselves to the record separator mode of deblocking 
(unless of course the data to be transmitted can be guaranteed 
not to contain a particular character). 


4. If multiple System/3s are to be multidropped on a single 
communication line, it is important for the Systemn/3 application 
program to take the necessary steps to assure a negative response 
to polling when communication is inactive between the System/3 
and IMS/VS. This usually requires the issuance of a GET type 
operation in the System/3 and the use of the cancel function when 
the next direction of transmission is to be a PUT type operation 
for the System/3. 
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SECURITY AND PRIVACY 


It is the objective of IMS/VS to provide safeguards through which 
access to data may be limited. The mechanics of the safeguard systen 
can be used to administer security and privacy policies. Administration 
ls accomplished by careful interpretation of policy in system and 
application design, and into parameters and control statements used for: 
system definition, the security maintenance utility, program 
specification block generation, data base description generation, and 
Statistical analysis progran. 


IMS/VS SECURITY WITH SMU 


The basic level of security is called default terminal security. It 
exists even if the user does not choose to use the additional security 
facilities provided by IMS/VS. 


To establish additional system security measures, the IMS/VS Security 
Maintenance Utility (SMU) can be run after the IMS/VS system definition 
is completed. SMU optional security measures include the following 
levels of security: 


e Terminal Security 

e Password Security 

® Resource Access Security 

e Transaction Command Security 
e Signon Verification Security 


MVS users can also specify use of the RACF program product, if desired. 
For more information on security see the section, "Establish IMS/VS 
System Security (Optional) in the IMS/VS Installation Guide. Security 
requirements may be redefined at normal restart, subject to limitations 
imposed by system definition, by the master terminal operator. The 
security modules specified by the master terminal operator or svstem 
definition will be loaded when IMS/VS is started. Security enforcement 
in IMS/VS involves the use of various tables or modules; these can be 
chosen or not, but they cannot be selectively replaced without rerunning 
SMU. 


t is recommended that the security measures be designed to require 
minimal master terminal operator action in normal situations. Although 
all documentation emphasizes the identity and importance of the master 
terminal, there are only a few characteristics that make it unique in 
the DB/DC system. It is the only logical terminal to which messages 
about the operational status of the system are automatically routed. It 
and the System 370 console are the only terminalis, by default, through 
which the DB/DC systen can be restarted. The control that the master 
terminal exercises over the system is made possible through the IMS/VS 
command language. 


A thorough examination of the commands, the system to be protected, 
the requirements of users, and the objectives of your security and 
privacy policy will provide guidance in the distribution of authority to 
use the command language. Refer to the IMS/VS Operator's Reference 


language. 
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Terminal Security 


Terminal security restricts the entry of transactions and commands to 
specified terminals. Link security (a subset of terminal security) 
allows the addition or deletion of transaction code security 
reguirements for the MSC links in a multiple IMS/VS system 
configuration. 


Through the entry of transaction codes, the terminal operator 
identifies the destination of the text or data that follows. When one 
examines the syntax of input messages, as defined by IMS/VS, it can be 
seen that all entries from terminals are classified by means of an 
identity code. In general, there are two levels of recognition. The 
first level establishes whether the entered data is a command by 
reserving the initial character /. The first character of every input 
segment is examined for a /. If one is present, the segment is treated 
as a command segment. Input destined to a program or logical terminal 
must not contain a / as the first character of any segment. The second, 
or operational, level verifies that the identity code is known to 
IMS/VS. If it is known, then it and the text that follows are 
classified based upon the attributes of the identity code. If the code 
was defined during system definition as a transaction code, the message 
is routed to the application program which is to process it. If the 
code was defined as a logical terminal name, then the message is routed 
to the physical terminal to which that logical terminal is attached. It 
becomes a message switch operation. 


The possible contents of a message destined for an application 
processing program, the actual functions which are performed by that 
program, and the content of any output subsequently generated by that 
program are unknown to IMS/VS. Because applications may deal with 
critical or private matters, safeguarding tools are provided by the 
system to help prevent unauthorized entry of transaction codes, and 
hence unauthorized use of appliction program functions. 


The entry of each transaction code can be limited to any one or any 
group of logical terminals in the system. Depending on the ratio of 
secured to unsecured transaction codes, the authorization plan that is 
developed can be inclusive or exclusive. To use the Security 
Maintenance Utility effectively, the operational plan must be inclusive. 
That is, you must specify the transaction codes which are to be secured. 
There is no provision for specifying those which are not to be secured. 
There are, however, alternative views of the plan that can be helpful. 
You can look at the transaction codes as being authorized for entry from 
a list of logical terminals. Or, think of each logical terminal as 
being authorized to enter a list of transaction codes. Either viewpoint 
may be translated easily into the operational input statements that 
describe what you want to do with the Security Maintenance Utility. 
However, the number of input statements can vary substantially between 
the two viewpoints. If, for example, you have one transaction code you 
want to authorize from five logical terminals, six input statements are 
required. Conversely, if you specify five logical terminals and 
authorize the same transaction code from each, ten input statements are 
required. 


Password Security 


Password security is used to restrict specified IMS/VS resources to 
someone who supplies the correct password. 
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Passwords can be used instead of, or in addition to, logical 
terminals to limit transaction entry. The security provided by 
passwords can be specified and viewed in the same manner as that 
provided through logical terminals. When a transaction is defined with ; 
SHU as reguiring a password, IMS/VS will not allow the user to execute 
the transaction unless the password is specified with the transaction 
code. 


Command functions can be protected against unauthorized use in four 
ways: by permitting the command verb to be entered only from certain 
logical terminals, by requiring that a password be entered with the 
command verb, or by a combination of both, or with transaction command 
security. Some objects of commands can be protected against 
unauthorized action by requiring a password to be entered with the 
parameter. The protection of the command object is controlled by 
assigning a protected attribute to each member of the class of objects 
to be protected. 


For example, to require a password be entered to alter the status of 
logical terminals (LTERM) 111, 222, and 333, one must specify to the 
Security Maintenance Utility a password for each terminal. If PTERMs 
111, 222, and 333 are the only LTERMs in the system and all are 
protected by the same password, then the object keyword is secured 
throughout the system. If, however, it is only necessary to protect 
LTERM 222, then the LTERM keyword can be used without a password on 
LTERMS 111 and 333. 


Another way to look at using safeguards to protect the command 
language is by individual user profile. Equate passwords to user signon 
or identification codes. An authorization plan can be developed that 
authorizes each user to use, individually, a set of command functions. 
That authorization could be localized geographically through restricting 
entry of the command verb to a group of logical terminals. 


A class profile system could be used. For example, password x - 
validates the use of four command verbs, YYYY validates three different 
command verbs. 2Z2Z22Z however is valid not only for the commands 
protected by x and YYYY, but also authorizes the holder to enter an 
immediate DB/DC system shutdown command from any terminal. 


Resource access security limits the set of IMS/VS resources which may 
be used by dependent regions that are authorized to access a specific 
Application Group. This group represents a set of user defined IMS/VS 
resources [PSBs, TRANS, and LTERMs). 


The IMS/VS SECURITY macro allows the user to specify during systen 
definition whether or not resource access security will be included in 
the system, and whether the RACF product or a user exit routine will be 
used for the authorization validation. The specifications may be 
overridden via an IMS/VS procedure parameter. RACF or a user exit 
routine, depending on the user specifications, will validate the 
dependent region authorization to use the Application Group. The same 
parameter (ISIS) can specify no resource access security checking be 
done. Subseguently, IMS/VS will ensure each time a request is issued 
that the TRAN, PSB, or LTERM is definad in the authorized Application 
Group. SMU enables the user to define the Application Groups and to 
indicate which resources are available for each group. 
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Transaction Command Security 


SMU can be used to designate transactions to be passed to an 
application program which is allowed to issue a subset of IMS/VS 
operator commands. The online application programs that process these 
transactions cause IMS/VS operator commands to be executed and can 
receive status on the execution of the commands. In the absence of 
specifications authorizing one or more of these commands, no transaction 
processing programs are allowed to enter IMS/VS commands. For more 
information on how to authorize transaction processing programs to issue 
IMS/VS commands, see the section, "Establish IMS/VS System Security 
{Optional)," in the IMS/VS Installation Guide. In addition, see the 
“Automated Operator Programming" chapter in the IMS/VS System 


SIGNON VERIFICATION SECURITY 

Signon verification security identifies a particular user to IMS/VS 
as being present from the /SIGN ON command entry until a /SIGN OFF 
command is entered to remove the association created by the first 
command. When transaction authorization is in effect for a physical 
terminal, as each transaction is entered from that terminal, a check is 
made to determine whether or not the transaction is authorized to the 
userid currently logged on. 


The IMS/VS security macro allows the user to specify during systen 
definition, whether signon verification only, or together with 
transaction authorization security will be included in the system. Both 
the user verification and the transaction authorization can be done by 
the RACF product, user exit routines, or by both. The specifications 
may be overridden via IMS/VS procedure parameters or /NRESTART command 
specifications. Since transaction codes are checked against the userid 
of the terminal operator entering the request, transaction authorization 
security requires user verification through the /SIGN ON command be 
performed as well. For information on user exit routines see "DC User 
Exit Routines" in the IMS/VS Systems Programming Reference Manual. 


The /SIGN command provides a means of identifying a particular user 
to IMS/VS as being present at the physical terminal. When a signon is 
processed, IMS/VS will verify through the RACF product, a user exit 
routine, or through both (depending on the system definition 
specifications and the IMS/VS start-up parameters), the user 
identification entered. Upon verification, IMS/VS creates a record on 
the IMS/VS system log associating the user with the physical terminal 
and records in a control biock that the terminal is signed on to a 
specific user identification. 


If transaction authorization is included, as each transaction is 
entered, the RACF product, a user exit routine, or both validate the 
transaction authorization for the user identification logged on. With 
program-to-program switching through the DL/I change call or by means of 
changing the transaction code in the SPA, the RACF product, the user 
exit routine, or both are also invoked for transaction level 
authorization checking. The same applies when the transaction code is 
changed by means of the /SET, /LOCK, or /UNLOCK commands. In addition, 
as the application program associated with the transaction produces data 
base changes, the user identification is logged with the change records 
on the IMS/VS system log to identify the changes performed by a specific 
user. When the /SIGN OFF command is issued, the session is terminated 
and another record is written to the IMS/VS system log. For more 
Manual. The identification of the physical terminals that require signon 
verification is done by the Security Maintenance Utility. For more 
information on the SMU, see the IMS/VS Installation Guide. 
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Other Security Aspects 
Consideration should be given to physical security measures that 
support system security measures. These measures may include: J 


e Controlled access to and egress from the computer area. 


® Authorization of DP operations and non-operations personnel in the 
computer and certain terminal areas. 


e Separately controlled areas for media such as tapes, disks, cards, 
files, or other media. 


e Control of computer forms. 


These are some of the considerations for physical security of a 
computer facility. Physical security needs are likely to be dynamic and 
merit periodic review and adjustment. 


IMS/VS does not provide a software function to blank out or 
obliterate passwords from the terminal device display media after they 
are accepted. However, Message Format Service (MFS) facilities enable 
users to define fields with a non-display attribute (for 3270 display 
devices). IMS/VS removes passwords from messages prior to recording 
them on the log. 


Most hard copy key-driven terminals have a feature which permits 
characters to be entered without displaying them. This feature is the 
bypass feature. Ordinarily, a terminal with this feature is operated 
continuously in display or bypass mode. If passwords are to be used to 
support security requirements, this feature is a necessity. ) 


The bypass feature can be used operationally, that is, by 


establishing standards for protection not only of passwords, but also of 
command verbs, commands, transaction codes, and text. 


Through centralized control over the content of Data Base 
Definitions, Program Specification Blocks and the libraries in which 
they reside, an effective scheme of prote cion attributes can be 
assigned to data. This assignment is made relative to each application 
program which has access to the data base. Thea smallest unit of data 
which may be so protected is the segment. The basic actions that can be 
authorized are; 

e None -- no access to segment type. 
e Read -- sagment type may only be retrieved. 


One or more of the following additional actions combined with read 
can be authorized: 


e Add -- new occurrences of segment type can be inserted. 
e Update -- an existing occurrence of a segment type can be replaced. 


e Delete -- an existing occurrence of a segment type can be deleted. 
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Although access authorization is declared at the program level, 
enforcement of the authorization can be made to appear at the 
transaction code or individual hierarchical level of a data base. If 
only one transaction code is associated with a particular progran, then 
the access authorization has been promoted to the transaction level. 
Through use of passwords or through use of the transaction code and 
terminal bypass feature, access authorization can be promoted to the 
individual level. 


For information about specifying segment access authorization, refer 
to "PSB Generation" in the IMS/VS Utilities Reference Manual. The 


control statements through which segment data access is authorized are 
PCB and SENSEG. 


3270 Switched Terminal Security 


3270s on a switched line can have their hardware IDs verified for 
authorization to access IMS/VS by use of the IDLIST macro. For 
additional terminal security information concerning 3270 switched 


Installation Guide. 


VIOLATION CONTROL 


IMS/VS records security violation attempts on the IMS/VS system log 
tape. The violations recorded are: 


e Input messag2 from an unauthorized terminal 

e Password omitted when one is required 

e Password incorrect for authorization 

e Misspelled password 

e Rejected Signon 

e Unauthorized DL/I CMD call from application progran 


IMS/VS rejects invalid input messages by sending a message to the 
terminal entering the message, and logging the violation. 


The log tape provides an audit trail to look into possible security 
problems. If more immediate action is desired, the user can request 
notification to the master terminal at the time of violation. Since the 
number of violations for a large network may be high due to misspelled 
passwords, transaction codes, commands, etc., the user can specify a 
threshold for notification such that the master terminal is not notified 
until the specified number of violations occur without a valid input 
from a given terminal. This eliminates or reduces the number of 
notifications due simply to operator error, while still providing 
evidence of real attempts to avoid security safeguards. 


IMS/VS security functions only as well as the installation controls 
over the environment. IMS/VS assumes nothing about the attributes of 
the caller and relies on the optional security tables, user exit 
routines, and RACF specifications to determine what resources the caller 
can access. 
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By using the Security Maintenance Utility (SMU), the user can specify 
several levels of security: terminal, password, transaction command, 
resource access, and us®2r verification. The output of the SMU is in the 
form of security tables and matrixes that are stored in the IMSVS. MATRIX 
data set. 


The IMSVS.MATRIX data set and the IMSVS.JOBS data set, which contains 
IMS/VS related jobs, may be secured by the user assignment of RACF 
password protection (MVS only). For more information on security 
implementation, see the IMS/VS Installation Guide, 


IMS/VS DC MONITOR 


The IMS/VS DC monitor is a tool for collecting performance data to 
investigate specific application designs, data base designs, and 
resource allocations. It consists of a monitor module, and a Monitor 
Report Print program. When activated, it analyzes and records the 
internal activities of the IMS/VS DB/DC system. The monitor report 
print program is processed offline to produce reports that summarize and 
categorize, at various levels of detail, the information recorded by the 
monitor module. The actions required to activate the monitor module are 
described in the IMS/VS Operator's Reference Manual. The monitor report 
print program is described in the IMS/VS Utilities Reference Manual. 

The monitor module collects data from IMS/V¥S DC control blocks during 
operation of the online system, with minimum interference to the systen, 
and records the data on an independent data set. The monitor remains 
resident and is activated and deactivated through master terminal 
control. 


Following are recommendations for use of the IMS/VS DC monitor: 


® Collecting data -- The IMS/VS DC monitor enables an IMS/VS DC user 
to collect performance data to assist in analyzing an existing 
IMS/VS online system. The amount of data collected and the analysis 
time to understand the report output suggest short traces during 
various time periods. Reports produced from profiles of a time 
period considered as normal can be used as a profile and compared 
with reports produced during a time period characterized by unusual 
responses. 


e Tuning system -- The IMS/VS DC monitor can be used to quantify the 
effect of actual changes to data base structures, program 
characteristics, data set placement, pool sizes, number of message 
processing regions, transactions, and message region class 
scheduling. 


e Testing application -- In the final testing of new or revised 
applications, the IMS/VS DC monitor can be useful in validating the 
internal operation of the programs and data bases. For example, the 
programmer thought a specific DL/I call could be satisfied with a 
Single I/0 retrieval, yet the DL/I call report indicated a large 
data base scan as shown by many IWAITs. Investigation of such items 
could assist in determining whether a new or revised application 
meets the performance objectives. Data contained in the reports may 
also assist in defining the resources required by an application 
program. 
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e Integrating applications -- The IMS/VS DC monitor can be used to 
determine the effects on the IMS/VS production system as new 
applications are merged from a test system to the production systen. 
One of the basic problems in integration of new applications into an 
existing system is the requirement of re-tuning options in the 
production system, such as data set placement and buffer pool sizes, 
as discussed above in the tuning of the systen. 


e Communicating criteria ~- If the above recommendations are 
implemented, then data is collected to establish a performance base, 
profiles are available for the problem periods, the system is tuned 
for the production and test systems, and applications are tested and 
merged into the IMS/VS production system with an understanding of 
their effects and interactions. Thus, the IMS/VS DC monitor reports 
can be used as a basis to communicate and define performance. 


This section describes IMS/VS sensitivity to specific characters when 
users attempt to send and receive nongraphic data in IMS/VS messages. 


EDITING OF OUTPUT MESSAGE SEGMENTS 


For output message segments that are edited by the Message Format 
Service (MFS), only graphic data (X"40* through X*FE') is allowed in the 
output message presented to the device. Nongraphic characters, if 
present in the output message, are changed by MFS before the data is 
presented to the device. Device control characters HT, CR, LF, NL, and 
BS are changed to xX'00' for 3270 video. For all other devices, these 
characters are changed to blanks. All other nongraphic characters are 
changed to blanks. 


If the Distributed Presentation Management (DPM) option of MFS is 
used for 3600 and 3790 controllers, the user may specify GRAPHIC=NO in 
the SEG statement. Nongraphic characters, if present in the output 
segment with GRAPHIC=NO specified, are presented unchanged to the remotes 
progran. 


For programmable terminals supported through VIAM, IMS/VS may insert 
function management headers (FMHs) and may perform additional editing 
for device control sequences when splitting a single IMS/VS segment into 
multiple transmissions. 


EDITING OF INPUT MESSAGE SEGMENTS BY MFS 


If MFS is defined for a device, the user should be aware of the 
following considerations: 


e The user should specify GRAPHIC=NO in the SEG statement to prevent 
uppercase translation on a segment if the destination requests it 
with the EDIT=ULC specification on the system definition TRANSACT 
macro. 


e For the first input record from a 274x, 3600, SCS1 or SCS2 device, 
or from DPM-An, the segment is discarded if the last characters of 
the segment are two asterisks (**) or two asterisks followed by NL 
{(X°15") or IRS (X'"1E*"). 
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e The presence of two slashes [//) at the beginning of a message 
segment is considered an escape sequence. (See the section "Input 
Message Formatting" in the chapter "Message Formatting Functions" in 
the IMS/VS Message Format Service User's Guide for additional ? 2 
information.) 


e If the card feature is defined for an SCS! device (with the CARD= 
operand in the DEV statement), the input from an SNA character 
string 1 (SCS1) device is scanned for the secure string reader (SSR) 
code and the code is removed. 


Note: The definition of the MFS delete characters (LDEL= operand in the 
DEV statement) and field tab character (FTAB= operand in the DEV 
statement) for MFS-supported devices, except the 3270, can direct the 
editing of input message segments. Refer to the IMS/VS Message Format 
Service User's Guide for information on using these specifications. 


EDITING OF INPUT MESSAGE SEGMENTS BY THE BASIC EDIT ROUTINE 


The following editing is performed if the IMS/VS basic edit routine 
is used: 


e For the first segment of an input message when a terminal is not in 
conversation mode, leading characters less than X'4l' are removed. 
For other than the first segment or when a terminal is in 
conversation mode, leading characters less than X*40" are removed. 


e If a terminal is not in conversation or preset mode, a left 
parenthesis within the first nine positions of the first segment 
indicates a password. The left and right parentheses and the 
password are removed, and the segment is compressed. 


e An X'26" character that appears as the last character in a segment } 
is removed. 


e Two asterisks (**) or two asterisks followed by NL (xX'15"') or IRS 
[X*1E") that appear as the last characters of a segment cause the 
entire segment to be discarded. 


e For unbuffered keyboard devices (for example, 1050, 2740-1, 2741), 
backspace [(X'16") characters are treated as character-delete 
indicators. Each backspace character and the preceding input 
character are removed from the segment. This editing is optional 
for the 3767 and 3770 consoles. 


e If the destination of the input message is a transaction, an NL 
(X*15") character appearing at the end of a segment is removed. 


e If a device is in preset mode, the transaction code is added to the 
first segment. 


e For input from 3270 devices, the attention identifier (AID) and 
cursor address are removed, and all start buffer address (SBA) 
sequences are changed to blanks. 


e If the first character of any segment is a slash (/), the entire 
input message will be treated as a command. 
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COMMON EDITING PERFORMED BY IMS/V¥S 


Certain common editing is done by both MFS and the basic edit routine 
for any device that enters an input message. 


e A slash (/) used as the first character of the first segment will be 
treated as an attempt to enter a command. 


e When a terminal is not in either preset or conversation mode, a 
transaction code or logical terminal name must be present in the 
beginning of the first segment. The transaction code must be 1 to 8 
characters in length and followed by a blank. 


e Uppercase translation is performed if it is specified in the system 
definition TRANSACT macro. 


e If a terminal was in conversation mode and the application 
terminates the conversation by inserting the SPA with the 
transaction code set to a nonconversational transaction code, this 
code from the SPA will be added to the beginning of the first 
segment of the next input message number. (See the section 
“Terminating a Conversation" in the chapter "Data Communication: 


Reference Manual for further details.) 


e When a conversation is started, the transaction code is removed from 
the first message segment and placed in the SPA. 


Note: This does not apply to MFS option 3 segments (see the IMS/VS 
Message Format Format Service User's Guide). 

e For devices supported through VTAM, IMS/VS removes the FMH (if any) 
that appears at the beginning of the first transmission of a chain. 


e For a 3770 or type 1 SLU card reader, Transmit Data Set {TDS), or 
User Data Set {(UDS) input, deblocking into IMV/VS message segments 
occurs at each inter-record separator (IRS) control character, and 
the IRS control character is discarded. 


® For 3767, 3770, or type 1 SLU consoles, deblocking into IMS/VS 
message segments occurs at each new line (NL) or forms-feed (FF) 
control character if the optional MFS editing is net selected. This 
character may or may not be discarded, depending on other criteria 
related above. 


e For 3614 work stations, message formats for transaction IDs and 
class fields must conform to the specification prescribed by the 
hardware. See IBM 3600 Finance Communication System 3614 
Programmer's Guide and Reference Manual for information on hardware 
specifications governing 3614 message formats. 


USIN 


NG THE 3850 MASS STORAGE SYSTEM (MSS) FOR DB/DC PROCESSING 


IMS/VS supports the IBM 3850 Mass Storage System (MSS) through its 
normal OS/VS1 and OS/VS2 interface. MSS extends the capacity of 3330 
Disk Storage. The uses of MSS with IMS/VS are: 

e As a residence device for batch and online data bases 


e For the development and testing of new applications 
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°e As the storage media for historical or cutoff versions of data base 


e As a centrally controlled location for data (DB/DC and other types) 
in a data processing systen 


Each of the preceding uses requires an understanding of the 
characteristics of IMS/VS and MSS that could affect an installation. 
This section presents the information needed to understand and take 
advantage of these characteristics. Design considerations and 
guidelines related to the following topics are described in detail. 


e Using MSS in a batch IMS/VS environment. 


e Using MSS in an online IMS/VS environment. Three different online 
environments, ranging from simple to complex, are described. 


e Sharing staging space. 
e Data base organization and access methods. 
e Using the additional capacity of the MSS with IMS/VS. 


In this section, MSS is described only as it relates to IMS/VS, even 
though the considerations and guidelines generally apply to any DB/DC 
system. Since no attempt is made to explain the facilities of MSS and 
its operating system support, you should be familiar with the following 
publications: 


e Introduction to the IBM 3850 Mass Storage System (MSS) 
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TERMINOLOGY 


The terms "stage," "bind," and “cylinderfault" are used in this 
Section. Stage, bind, and cylinderfault specify how data that is stored 
on an MSS volume is to be staged. 


Stage: Stage specifies that the data is to be staged from mass storage 
to a direct-access staging device when the cluster or component is 
opened. If it can't be staged at the time the cluster or component is 
opened, because of other staging activity, data is staged as a 
processing program needs it through page fault. 


Bind: Bind specifies that the data is not only to be staged but also to 
be kept on the direct-access staging device until it is closed. If it 
can't be staged at open time because of other staging activity and if 
there is staging pack space available for the entire data set, data is 
staged as a processing program needs it through page fault. 


Cylinderfault: Cylinderfault specifies that the data is not to be 


staged when the data set is opened. It will be staged as the processing 
program needs it. 


As a general rule, MSS can be used in a batch IMS/VS environment in 
stage, bind, or cylinderfault mode. In an online environment, it is 
recommended that the data base reside on real DASD or that it be staged 
with the bind option if transaction throughput and response time are 
critical. 
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IMS/VS BATCH ENVIRONMENT 


Figure 2-11 shows the use of MSS in an IMS/VS batch environment for 
data base residence. A batch environment that includes MSS allows: 


e Operational control of an entire system of data bases and files 
through MSS. 


e An extra dimension of flexibility because processing of large data 
bases can be done with fewer staging drives compared to the number 
that would be required if real drives were used. In this 
environment, it might be more efficient to do some types of 
processing at a reduced throughput rate and save the investment in 
additional disk drives. 


e The testing of large data base applications can be done using fewer 
staging drives than would normally be required in a production 
environment; this can be tailored to meet the needs of an 
installation. 


Staging 


Mass Storage Facility 





Figure 2-11. MSS in an IMS/VS Batch Environment 


The paragraphs that follow describe how MSS can be used to advantage 
in an IMS/VS batch environment with certain disk drive saving 
opportunities. You may know from experience that you will process only a 
fraction of a very large data base. For example, only 10% of an 
insurance data base might have policy updates, claims, or billing 
activity in the course of a day. If the full data base occupied 10 disk 
drives, then some number of staging drives equal to or less than 10 
might be sufficient to handle the day's activity in cylinderfault mode. 
The exact number of staging drives required would depend on data storage 
patterns, reuse of staging drive space, the distribution of data across 
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cylinder pages, and MSS staging algorithms. The MSS publications 
referenced earlier contain detailed information on these factors. 


If you know the reference patterns that your applications require, j 
then possibly only a DL/I data set group has to be staged for 
processing. 


Month-end cutoff processing of a data base also lends itself to the 
use of MSS with IMS/VS batch. Ina non-MSS environment, a month-end 
cutoff copy of a data base is normally gotten by copying the data hase 
to tape. The tape is later restored to disk so month-end reports, etc., 
can be written from the month-end copy of the data base. The MSS allows 
you to destage a month-end cutoff to MSS cartridges; later stage the 
data from the cartridges, possibly to a subset of data base staging 
drives; and process the month-end cutoff data without having to go 
through disk to tape and tape to disk dumps and restores. 


IMS/VS ONLINE (DB/DC) ENVIRONMENT 


Just as MSS offers an added dimension of flexibility in an IMS/VS 
batch environment, there are added opportunities in an online 
environment, but planning is far more critical. An online DB/DC 
environment usually includes certain transactions that require fast 
response and throughput as well as fast recovery. These transactions 
will be referred to as critical transactions. 


In the online environment the following assumptions are made: 


e Response time and transaction throughput for critical transactions 
should be the same whether or not MSS is part of the operational 


environment. 

e Recovery time in the event of an IMS/VS, OS/VS, or hardware failure ) 
should be the same in an MSS environment as in a non-MSS 
environment. 


To maintain the response and recovery time criterion required by your 
installation and still use MSS effectively in an online IMS/VS 
environment requires that you consider the following factors during 
planning: 


e Logging and restart processing 

e Sharing of staging drives 

e Sharing of data bases 

e Update activity 

® Initialization and prestaging 

The following contains considerations and guidelines for these 
factors in each of three different online environments: (1) IMS/VS 
online using bound data or real DASD and no batch applications, (2) 
IMS/VS online bound data using bound data and/or real DASD with IMS/VS 
batch, and (3) INS/VS online using some bound and some unbound data. 

Additional factors, data base organization and access methods, apply 


equally to all environments and will be described as a separate topic 
later in this section. 
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IMS/VS Online Using Bound Data and/or DASD without Batch 


This is the simplest online environment to plan for. IMS/VS logs the 
system activity and runs recovery as necessary using the log tape much 
the same as in a non-MSS environment. Because alli data is either 
mounted and bound on staging volumes or residing on real DASD, there is 
minimal planning necessary for sharing staging DASD. The sharing of 
data bases by multiple Message Processing Programs (MPPs) requires the 
same planning as in a non-MSS environment. Figure 2-12 shows this kind 
of environment. 
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Figure 2-12. MSS in an IMS/VS Online Environment with Bound Data 


Initialization and prestaging must be planned if real DASD is not 
used. If the data is to be bound, it is important to ensure that the 
data be staged and bound on the staging packs before starting IMS/VS 
Online operations. If the staging packs are used to hold only the bound 
data, and never used to hold other data, then the data is staged and 
bound once, and it does not have to be restaged and bound each time 
IMS/VS is started. However, if the staging packs are used for other 
work (for exampla, during off-shift operations), the staging and binding 
of IMS/VS online data must be scheduled before starting IMS/VS at the 
beginning of each work day. The process of staging and binding data can 
be a lengthy process requiring careful scheduling to ensure that it 
completes prior to starting online IMS/VS operations. Also, there 
should be sufficient staging pack space available to hold all the data 
to be staged and bound. 
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Methods of staging bound data prior to data set OPEN processing are 
contained in “How to Use the Additional Capacity of MSS with IMS/VS" 
later in this section. 


All planning considerations are the same as in the previous 
environment if the IMS/VS batch is also using bound data and/or real 
DASD, which is unlikely. If IMS/VS batch is cylinderfaulting to the 
Staging volumes, there could be a delay as IMS/VS batch and online 
contend for staging pack space. As a general rule, if IMS/VS batch will 
cause contention for staging pack space, stage and bind the critical 
online data before the batch operations begin. 


Although this example uses IMS/VS online and batch, the same 
considerations apply to any activity (OS/VS batch, TSO, etc.) running 
with an online IMS/VS system. See "Sharing of Staging Space" in this 
section for additional information on this topic. Figure 2-13 shows 
this kind of environment. 
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Figure 2-13. MSS in an IMS/VS Online and Batch Environment 
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Recovery should be the same in this environment as in a non-MSS 
environment because IMS/VS online has its own separate logging facility 
and data bases are not shared between online and batch operations. 
Operational procedures may differ, however. For example, where batch 
backout in a non-MSS environment involves gquiescing activity to a data 
base, closing the log tape, and moving the data base and log tape toa 
different address space or CPU, the MSS environment involves quiescing 
the activity to the data base, closing the log tape, demounting the 
virtual volume, and remounting the virtual volume for batch backout. 
Again, this procedure varies depending on where batch backout is to be 
run: in the same host or in another host of a multihost system. Destage 
and restage may Or may not be necessary at batch backout time depending 
on the configuration and the virtual unit address [VUA) specified in the 
mount order for the mass storage volume at initial IMS/VS load. 


Even though staging packs with their virtual volume data cannot be 
physically moved from one staging disk drive to another, as is often 
done for batch backout with real DASD, the data can be moved (destaged 
and staged to another disk drive) to accomplish the same purpose. 


IMSZVS Online and Batch Using So 


This environment requires considerable planning. Again, the 
objective is to work in this environment and for certain critical 
transactions to maintain the same response time and throughput as well 
as recovery time, in the event of failure as would be experienced in a 
non-MSS environment. Figure 2-14 shows this kind of environment. 
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Figure 2-14. MSS with IMS/VS Online and Batch and Non-IMS/VS Data 


The data to be bound should be staged onto the staging packs before 
IMS/VS transaction processing begins assuming there will be contention 
for the staging packs. Next, data sets cr data set groups that will be 
referenced should be staged onto staging packs. Also, selected portions 
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of a data base that will definitely be referenced, if that can be 

determined, can be staged onto the staging packs. This might be 

accomplished by starting a batch message processing (BMP) program that 

issues DL/I calls causing selected data to be staged in cylinderfault ; 
mode. This essentially 1s prestaging. Prestaging data to staging packs , 

is somewhat analogous to putting and keeping data in the data base 

buffer pool for future reference. 


Prestaging through an IMS/VS application program can he very 
effective in a DL/I environment because it allows the user to stage 
selected portions of the DL/I data base using the standard DL/I 
facilities. 


Frequently the data base references patterns cannot be determined. 
For example, it is almost impossible to determine which customer of an 
insurance company will phone to report a theft. Prestaging, in this 
case, could be accomplished by entering a simple transaction that does 
no more than read the data From the data base using DL/I for the 
customer phoning the report. This would cause cylinderfault staging of 
policy information about that customer while information for a more 
complex transaction is being gathered based on the conversation between 
the insurance agent and his customer. 


This environment assumes a mix of transactions in the system, some 
critical transactions requiring fast response and throughput as well as 
fast recovery in the event of failure, and transactions that are not so 
critical. 


Since both the critical and the noncritical transactions share the 
same log tape used for emergency restart, and since critical 
transactions require a fast restart, it is important that cylinderfaults 
do not occur during emergency restart. This can only be guaranteed in 
this environment if all data required at restart time is available on 
real DASD or staging packs. This means that either there must be enough 
staging pack space available so data is never destaged to make room for 
Other data, or that there is no update activity to data bases running in 
cylinderfault mode. Data base updates could cause cylinderfanlting 
during emergency restart if the changed data base records had been 
destaged to MSS cartridges to make room for other data on the staging 
packs and some of the data that had been dastaged was required during 
restart. Emergency restart of critical transaction activity would be 
delayed by cylinderfaulting of noncritical transaction activity hecause 
backout is done serially. 


L 


If only BMPs are using online data bases in cylinderfault mode then 
specifying NOBMP at emergency restart would eliminate the backout of BMP 
updates and the delay to emergency restart caused by cylinderfaulting. 


In addition, batch backout and program isolation dynamic backout will 
take longer if cylinderfaulting must occur during backout. Similar 
guidelines apply to batch backout and program isolation dynamic backout 
as apply to emergency restart with the exception of NOBMP, which applies 
only to emergency restart. 


The preceding point regarding no update activity for data bases 
running in cylinderfault mode may appear restrictive. It is only a 
recommended guideline to ensure fast emergency restart. It is also 
tunable where the number of emergency restarts or batch backouts, the 
number of apdates, and the degree to which staging pack space is 
overcommitted are the tunable considerations. For example, it may be 
satisfactory to allow updates to data bases running in cylinderfault 
mode depending on the number of updates per sync point or checkpoint, or 
if emergency restarts are infrequent. 


2-88 IMS/VS Systea/Application Design Guide 


Data bases that are read to gather data to generate reports are 
likely candidates for use of shared, overcommitted staging pack space. 
An example here might be month-end accounting reports that are generated 
from month-end cutoff versions of a data base. 


In this environment, transactions requiring fast response and 
throughput should not be scheduled to run in the same message processing 
region as transactions that could require cylinderfault staging. The 
critical transactions could end up being queued until transactions 
requiring a call for data on MSS have completed. 


Message class scheduling affects the queuing of transactions in 
IMS/VS. Transactions requiring fast response and throughput should be 
assigned to a separate class from transactions that could require 
cylinderfaulting. The classes should then be assigned to separate 
regions when IMS/VS is started. 


The MSS staging drive group concept can be used for added tuning in 
this environment. Not all data bases have to use the same level of 
overcommitment. Staging drives can be divided into staging drive groups 
so that there may be more contention for staging drive space for very 
low priority work and less contention, or even no contention, for higher 
priority work. Activity from work outside the IMS/VS online systen, 
such as batch work, could adversely affect the IMS/VS online system if 
all work shared the same staging drive group and the scheduling of work 
was not otherwise controlled. 


The sharing of data bases has to be well planned in this environment. 
Avoid having a transaction that requires fast response use data fron 
both a data base on a bound volume or real DASD and also from a data 
base residing on overcommitted staging packs. Also avoid a logical 
relationship between these same two data bases where processing, 
especially insert or delete processing, could slow down processing of 
the bound or real DASD data base. 


Also to be avoided, but less obvious, is a situation with the 
following or equivalent characteristics: 


e Program A scheduled by transaction A requires fast response. 
e Program B scheduled by transaction B does not require fast response. 
e Program A uses data base A which is on bound staging packs. 


e Program B uses data base B which is on overcommitted staging packs 
and also uses data base A. 


Figure 2-15 shows this situation. It is possible that a program B 
could impact program A's processing and it would depend on the extent to 
which program 2 was holding data from data base A while staging data 
base B, and program A required the same data being held by program B. 


This may be an unusual situation but it points out that application 
scheduling and use of data bases in this environment should be well 
planned to avoid less obvious throughput problems. Again, the same 
caution regarding doing updates to a data base on overcommitted staging 
packs, as described earlier, applies in the above example. 
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Figure 2-15. MSS in an IMS/VS Environment Using Shared Data Bases 


SHARING OF STAGING SPACE 


Closely related to the sharing of a data base is the sharing of 
staging space. Staging space sharing considerations were partially 
described under the second and third environments earlier in this 
section. Well planned use of the MSS staging drive groups is a valuable 
way to control the amount of staging pack space allotted to various 
applications or data bases. 


When allocating staging space for IMS/VS, view the entire system as 
known to MSS. This could include not only IMS/VS online and batch 
systems, but non-IMS batch or TSO, for example. Staging pack space may 
be known to MSS across multiple CPUs. It is necessary, then, to 
consider possible interference to IMS/VS processing from outside of 
IMS/VS itself. MSS staging drive groups can be used to help control 
unwanted staging from shared staging space. This should be well 
planned, because there could be interactions between the IMS/VS and 
non-IMS/VS environments. The use of staging drive groups is further 
described under the topic "How to Use the Additional Capacity of MSS 
with IMS/VS." 


DATA BASE ORGANIZATION AND ACCESS METHOD 


ISAM data sets can only be accessed in the cylinderfault mode. This 
means that the ISAM portion of an ISAM/OSAM data base cannot be staged 
or bound at OPEN time; the time of the first DL/I call. Staging of a 
cylinder of data takas place only as the result of a DL/I call for data 
in that cylinder. It then follows that if ISAM/OSAM is used, and 
cylinderfaulting presents an unwanted delay, some form of prestaging or, 
better yet, VSAM should be used. 


OSAM data sets can only he defined with the stage attribute. Because 
OSAM uses EXCPVR, the operation of MSS with EXCPVR applies to OSAM. The 
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OSAM portion of an ISAM/OSAM data base will be staged at OPEN time 
because that is when the data sets using EXCPVR are staged. 


The entire extent of an OSAM data set will be staged, even at initial 
load time. An exception to this occurs wher IMS/VS uses QSAM to write 
an OSAM data set as in recovery when the DFSRRCOO PARM is UDR. Onder 
such a condition there is no staging of the output data set at OPEN 
time. 


OSAM data sets cannot be bound. Therefore, there are some 
implications that should be considered. Even though the data requested 
in the first DL/I call will be returned to the application as soon as 
the requested page is staged, the entire data set will be scheduled for 
staging at the time of the first DL/I call. If you can determine ahead 
of time that data from the ISAM/OSAM data set will be required, it might 
be advisable to do one of the following: cause staging to begin shortly 
after IMS/VS is started by scheduling a simple application that issues a 
DL/ZI call to the ISAM/OSAM data base, or cause staging of the OSAM data 
by running a short IMS/VS batch job ahead of the IMS/V¥S job that 
requires the OSAM data to be staged. The IMS/VS batch joh would issue a 
DL/I call, which would cause OPEN and staging. At the end of the batch 
job the data would remain staged. This assumes there is enough staging 
pack space available for the OSAM data. It also assumes other activity 
in the system does not cause destaging of the OSAM data before it is 
needed. Refer to "Data Reuse" in the Introduction to the IBM 3850 Mass 
Storage System {MSS) manual for details on the reuse of virtual volume 
data. 


VSAM data bases can have the stage, bind, or cylinderfault staging 
attribute. Also, VSAM data can be destaged synchronously or 
asynchronously, where ISAM/OSAM data bases can only be destaged 
asynchronously. 


The following points should be considered in determining whether a 
VSAM data base should be destaged at CLOSE time with the delayed 
response reguest. Destaging at normal CLOSE time with the delayed 
response request causes synchronous destaging and insures successful 
destaging of the updated cylinders before CLOSE is complete. However, 
there are conditions under which IMS/VS closes a data base during 
On-line processing, for example, if the DMB pool runs out of space, or 
if the /DBR command stops the data base. Under such a condition the 
IMS/VS control region waits for CLOSE processing to complete before 
allowing any other on-line processing to proceed. This temporarily 
stops all on-line processing until the destage of updated cylinders 
completes if the data base was closed with delayed response. Each 
installation has to determine how it wants to close its data bases 
depending on the frequency of situations that can close a data base 
during on-line operations, the importance of never interrupting on-line 
operations, and the importance of insuring a successful destage of 
update cylinders at CLOSE time. 


In general, data bases should be VSAM based to provide maximun 
flexibility in both staging and destaging. For a very large noncritical 
HISAM or HIDAM data base, it might be desirable to define the HIDAM 
index cluster or the HISAM index component. of the KSDS as bound and the 
data portion as cylinderfault. This could be somewhat better than 
accessing the entire data base in cylinderfault mode, and it would 
require bound disk drive space for just the index portion of a large 
data base. 


The same guideline applies to secondary indexing. It might be 
helpful to define the secondary index as a hound data set. 
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HOW TO USE THE ADDITIONAL CAPACITY OF MSS WITH IMS/VS 


Since MSS offers a vast amount of storage beyond what has, in the 
past, been used in an IMS/VS system, it is meaningful to ask how that 
additional storage should be used. What kind of work can be put on 
IMS/VS given the added capacity of the MSS? 


As a general rule, applications requiring a small number of large, 
infrequently referenced, preferably read-only data bases, where response 
time or batch turnaround time is not critical, can be added to an 
existing IMS/VS system to take advantage of the additional capacity of 
the MSS. 


The applications could be new or they could be old ones that 
previously required data to be restored to disk from a save tape before 
they could be run. 


It is likely that the added applications would run in cylinderfault 
mode to avoid an investment in additional disk drive space. It then 
follows that the new applications would use new data bases that are 
separate from the existing critical IMS/VS online data bases. 


The added data bases should be infrequently referenced. Added work 
in cylinderfault mode could eventually impact existing work in the MSS 
system as the staging facilities of the MSS are absorbed. This cannot 
be quantified because it depends on the existing load on the IMS/VS MSS 
system, but it should be considered. 


It is recommended that the new applications be read-only because 
changes to a data base reguire a destage of updated cylinders. 
Therefore the impact of additional applications can be minimized by 
adding mostly read-only applications to the IMS/VS MSS systen. 


An example of a new application is a report writing application using 
a small amount of data from a large data base. 


The staging and binding of data in an IMS/VS environment can be 
handled in several ways depending on when the user wishes to experience 
a possible delay for staging. As stated earlier, if staging packs are 
not used for other work during off-shift operations, then there is no 
staging reguired each day because the data still exists on the staging 
packs. Staging at a data set level is determined at data set OPEN time 
based on the DEFINE attributes for the data set. Since IMS/VS OPENs a 
data set only when required at the first DL/I call, any necessary data 
set staging could take place at the first DL/I call. Again, if the 
staging disk drives were not used for other work, this would not cause 
any delay in processing at the first DL/I call. 


If your IMS/VS installation requires that bound data be available for 
critical processing during a relatively short period of time, for 
example 8 to 12 hours a day, it might be better or necessary to use the 
staging disk drives for other off-shift work. After the off-shift work 
has completed, and before IMS/VS critical processing is again started, 
it might be advisable to run a short IMS/VS batch job that OPENs the 
critical data sets and causes restaging and binding of the critical 
data. Then when IMS/VS critical processing is started, there will not 
be a delay for staging at the first DL/I call. 


Because most installations require IMS/VS to be up for more than one 
shift, it is not necessarily restrictive to dedicate bound staging space 
for certain critical data bases. This can greatly reduce the staging 
time that might otherwise be required if staging space was used for 
other work during off-shift operations. 
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If certain staging drives are to be dedicated to bound staging space 
that will not be used by other work during off-shift, they should be put 
in a separate staging drive group to ensure that the disk drives are not 
inadvertently used when IMS/VS is stopped. 


The staging drive groups are set up at MSS Table Create time. IMS/VS 
data sets are allocated to the staging drive groups as part of normal 
IMS/VS initialization via the UNIT assignment in the DD statements for 
the data bases. 


This section has described some of the points that should be 
considered to effectively use MSS with IMS/VS. With proper planning, 
the MSS can provide both added storage capacity and flexibility to the 
ImMS/VS systen. 
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CHAPTER 3. APPLICATION PROGRAM DESIGN 


This chapter includes considerations for design of both IMS/VS batch 
and telecommunication applications. Information concerning the data 
base interface applies to batch and online applications. The designer 
of a telecommunication application should cover all material in this 
chapter prior to designing his application. The designer of the batch 
application need only cover the material relating to batch applications, 
but is encouraged to cover the entire chapter prior to design of an 
application. 


BATCH APPLICATION PROGRAM DESIGN 
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GENERAL CONSIDERATIONS 


Design Of IMS/VS batch application programs deals with the 
environment shown in Figure 3-1. This environment is established 
through the IMS/VS system definition utility. Considerations for 
establishing this environment can be found in Chapter 2 of this manual. 


The application program, in conjunction with IMS/VS, runs as an 
Operating system job in VS1 or VS2. For the individual application 
program design, DL/I can. be looked at as an additional access method. 
The logging facility is a system function and does not involve the 
application program directly. Changes to the data base are 
automatically logged. Instead of the standard OS/VS terminology of 
SYSIN {input) and SYSOUT {output), TRANSACTION input and RESPONSE output 
respectively are used. This choice of nomenclature is used to encourage 
the design of a transaction-oriented systen. 


A transaction-oriented system can reduce recovery problems for 
program abnormal terminations and system failures. A 
transaction-oriented system is one in which there is a definite point at 
which each transaction {input) is considered complete. This point must 
be prior to receiving the next transaction. This isolates recovery 
problems to a particular transaction. 


Design of the application program must be done in concert with data 
base design. Each influences the other. With good communications 
between application design and data base design, a more viable system 
will be developed. A viable system is one which accommodates change 
with minioum modification. 


Programs that are OS/VS subtasks of an application program called by 


IMS/VS must not issue DL/I calls. If they do, the results will be 
unpredictable. 
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Figure 3-1. Batch Application Program Design 


Programming Language to be Used 


The use of IMS/VS should have little influence on the choice of a 
programming language for the application. The standard operating system 
CALL interface is used for COBOL, PL/I, and Assembler. IMS/VS offers no 
special advantage to these languages. However, the basic benefits 
attained by using a high levei language do apply. 


The Program Module Preload function of IMS/VS does offer a potential 
performance improvement, if application programs are written to be 
serially reusable or reenterable. 


Future Conversion to Telecommunication 

When designing an application program it is important to determine if 
there is a possibility of converting the program to a message processing 
program to be used in a telecommunication system. Making this 
determination prior to design of the application can save conversion 
time and cost. 
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Figure 3-2 shows the essential difference between the batch and 
telecommunication applications with IMS/VS. In the batch environment, 
the application program deals with DL/I for data base input/output and 
| with OS/VS data management for external input/output such as SYSIN and 
es SYSOUT. The same application program is shown below after being 

converted to a telecommunication application. The basic change is the 
replacing of READ/WRITE or GET/PUT logic with calls to DL/I for external 
input (TRANSACTION) and output (RESPONSE). 
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Figure 3-2. Planning Future Conversion to Telecommunication 
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By centralizing the statements in the batch application program which 
deal with external input/output, the future conversion to 
telecommunication can be made with a great deal more ease. 


BATCH CHECKPOINT/RESTART CONSIDERATIONS 


A general facility for batch checkpoint/restart is provided. It 
consists of a DL/I call function for checkpoint (CHKP) and the batch 
backout utility program. Batch checkpoint/restart can be complemented 
either by OS/VS checkpoint/restart or by installation-supplied 
checkpoint/restart routines. Installation-supplied routines can be 
Simplified by using the IMS/VS restart call (XRST) and user-area 
parameters on the CHKP call. ) 


To use batch checkpoint/restart, the application first invokes its 
complementary checkpoint routines. If the user wants to issue an OS/VS 
checkpoint within a batch only region, he must first close all open data 
bases, generate a uniques checkpoint ID, issue an OS/VS checkpoint macro, 
and issue the DL/I call with a matching checkpoint ID (this is required 
because OS/VS restart does not restore data management storage in 
total). If the user wants IMS/VS to issue an OS/VS checkpoint for hin, 
a fourth parameter, which points to an OS/VS checkpoint DCB, must be 
specified for the DL/I checkpoint call. Upon completion of those 
routines, and before issuing any other DL/I call, a DL/I checkpoint call 
is submitted. Along with the checkpoint call, the application passes 
the identification of its previously completed complementary checkpoint. 
DL/I ensures that all pending data base activity is physically recorded. 
Then the supplied checkpoint identification is recorded on the log tape 
and supplied to the operator in a WTO message. Control is returned to 
the application program, which can then proceed to execute, submitting 
other DL/I calls as necessary. 


To restart at a selected checkpoint, the batch backout utility is 
used to restore the data bases to their condition at the time of the 
checkpoint. Then the batch job is restarted at the same checkpoint. 


ESTABLISHING USEFUL CONVENTIONS 


Designing applications for use with IMS/VS affords an opportunity for 
establishing useful conventions and procedures. Adopting conventions 
which prove useful in application design and implementation can reduce 
costs and development cycle time. 


Testing 


Each program that is designed and implemented must be tested. 
Testing the application requires a test data base. A test data base 
requires a data base description generation, a program specification 
block generation, and a data base load program. Since a number of 
application programs will he dealing with the same data structure, a 
central agency for generating and maintaining test data bases should 
exist. 


It is important to establish naming conventions for data bases, data 
segments, fields, PSBs, and programs. A requirement in the IMS/VS DB/DC 
system is that the name of the PSB and the application program must be 
the same. Adopting this convention in the batch system can reduce 
conversion time. 
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As the system increases in scope through time there will be multiple 
data bases, each with a number of different segment types. One naming 
convention which can be helpful is to adopt a two-character code as the 
first two characters for a data base name. This two-character code can 
then be used as a prefix for all segment names within the data base. 
This ensures that no two segments will have the same name, eliminating 
communications problems. 


As the system becomes more complex with the relationship of programs, 
PSBs, data bases, segment types, and fields, a dictionary will be 
necessary. Questions such as, "What data segments and fields does this 
program update?" or "Which programs update this segment?" could be 
included ina data dictionary. Maintenance and control of such a 
dictionary should be the responsibility of the Systems Operation 
personnel responsible for all system control. 


Use of COPY or INCLUDE 


Extensive use of COPY or INCLUDE can be made for segment I/O area 
definition, PCB masks, and Segment Search Arguments (SSAs) within an 
application program. The use of COPY or INCLUDE in conjunction with a 
data dictionary can reduce maintenance disruptions to a mininun. 


Figure 3-3 shows an application program that is making use of 
standard operating system data sets and DL/I data bases. DL/I makes use 
of standard OS/VS data management facilities and provides a special 
access method called OSAM {Overflow Sequential Access Method). 
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Figure 3-3. Application Program Using OS/VS Data Files and DL/I Data 
Base 
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A parallel can be drawn between operating system data management 
input/output and DL/I input/output. Figure 3-4 shows an application 
program making use of the READ/WRITE logic of COBOL, which in turn makes 
use of a file description block. The same program is also reading and 
writing a data base through DL/I. The DL/I interface makes use of the 
standard OS/VS CALL facility. The control block for DL/I that replaces 
the file description of the operating system is called a program 
communication block (PCB). Just as a file description block is used for 
each file that is accessed by a program, each logical data structure 
that is accessed requires a program communication block. The IMS/VS 
Application Programming Reference Manual provides a discussion of 
logical data structures and their relation to data bases. 


A unigue characteristic of the application program interface with 
DL/I is that all information passed across the interface is described 
symbolically. There is nothing in the interface definition which 
relates to a specific access method or physical storage organization. 
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Figure 3-4. Application Program Using COBOL READ/WRITE Logic and File 
Description 


Details of CALLs to DL/I can be found in the IMS/VS Application 


Traditionally, application programs have been designed to obtain an 
entire record from a file and then deal with only selected portions of 
the record for reference or update. The application program was record 
Oriented. With DL/I, the application program is designed to obtain only 
those portions of the record necessary to perform the required 
procedure. I/0 is on a segment basis. The segment can contain one or 
more fields of information. 


The fact that I/O is on a segment basis should have some influence on 
the design of the application, as well as on the design of the data 
base. Once a segment is retrieved with a Get Hold type call, the next 
call using the same data base PCB can be a replace or delete call. If 
an intervening call is made, it would be necessary to do another Get 
Hold type call to update the segment. One way to avoid this is to use 
multiple data base PCBs for the same data base. This allows nultiple 
positions, as well as multiple segments, to be in HOLD status at one 
time. 
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Using the Right DL/I Call 

Application programmers are sometimes faced with a decision 
concerning the use of DL/I function codes and segment search arguments. 
A function code is a four-character code which is supplied to DL/I by 
the calling application program to specify the input/output function to 
be performed. SSAs (segment search arguments) are used to give specific 
information about the path to be followed in satisfying a call. SSAs 
are qualified or unqualified. An unqualified SSA specifies only the 
name of the desired segment. A qualified SSA specifies, in addition to 
the segment name, a field name within the segment, a relation operator, 
and a comparative value. 


For segment insert, delete, and replace, there is only one code for 
each specific function to be performed. For the segment retrieval 
function, however, there is a family of function codes: GET UNIQUE (GD), 
GET HOLD UNIQUE (GHU), GET NEXT (GN), GET HOLD NEXT [GHN), GET NEXT 
WITHIN PARENT (GNP), and GET HOLD NEXT WITHIN PARENT (GHNP). Each of 
these call functions provides for a variation in the method of 
retrieving a segment, depending on the existing position in the data 
base and the segment qualification. There are times when more than one 
of these calls will accomplish the same thing. 


When faced with a choice of GU, GN, or GNP with or without the HOLD 
option, there are a number of considerations. In addition to choosing a 
function code, the question of whether or not segment search arguments 
(SSAs) should be provided must be answered. If the SSAs are provided, 
the guestion of qualified or unqualified must be answered. 


Generally speaking, the GU call is used to retrieve a specific 
segment or to obtain a specific position within a data base. The GN or 
GNP only moves forward in the data base, except when the F command code 
is used. Once a logical position is established within a data base, the 
GU or the GN and GNP, used in conjunction with the F command code, are 
the only calls which can establish a position at some earlier logical 
point in the data base. 


There is no measurable difference between a GU, GN, or GNP call, if 
each has fully qualified SSAs and no logical position exists within the 
data base. If a logical position exists and movement is forward, a GN 
or GNP function call may be more efficient. An additional difficulty in 
making a choice of GU function calis comes when there is insufficient 
knowledge to provide complete qualification. 


Normally, a GU cail requires more time to execute than a GN or GNP 
call statement. 


The implications of providing unqualified segment search arguments 
can be seen in Figure 3-5. The call on the left has an unqualified 
segment search argument at level two for B. As a result, DL/I searches 
through all Segment Bs under Segment A with key of 6. All Segment Cs 
are searched before finding that the call cannot be satisfied. The call 
on the right is the same, except that the segment search argument for B 
is qualified at level two. When DL/I encounters the B with a key of 4, 
the search ends. At this point, DL/I realizes that the call cannot be 
satisfied. 
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Figure 3-5. Qualified Segment Search Arguments 
E 
RELATIONSHIP BETWEEN DL/I CALLS AND PHYSICAL I/O OPERATIONS 


Although DL/I calls issued by application programs are independent of 
the physical storage techniques used to store and access data, it is 
important for the reader to understand the the physical I/0 operations 
performed by IMS/VS. The use of any DL/I call may or may not require 
physical I/0 operations. If the DL/I call can be satisfied from 
information in the data base buffer pool, no physical I/O operations are 
required. When this is not the case, the actual physical I/0 operations 
performed depend upon the following: 


e The DL/I call issued 
e The physical data base access method and organization 


e The current position in the data base known by the DL/I control 
blocks for this application's use of the data base 


e Information in the data base buffer pool 
The following tables should be of assistance in understanding the 


physical I/0 operation which may be performed in satisfying GET UNIQUE 
(GU) or GET NEXT (GN) calls. 
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DL/I 
CALL 


FUNCTION 


IMS/VS DB/DC CONTROL PROGRAM 


| 
| VSAM-Get 
} Direct 

} or BISAM 
| or OSAM 
| Read 


I 

| VSAM-Get 
} Direct 

{| or BISAM 
| or OSAM 
}] Read 


VSAM-Get 
Direct 
or OSAM 
Read 


VSAM-Get 
Direct 
or OSA 
Read 


ACCESS METHOD 1 
HIDAM | 

wo wwe @ www ow ww ww ww ww ow www we ! 
INDEX | HIDAM | 
Data Base | Data Base { 
| | 

VSAN-Get {[VSAM-Get Direct] 
Direct | ! 
Or BISAM for OSAM { 
Read | Read | 
or OSAM | | 
Read 1 ] 
| l 

VSAM-Get {VSAM-Get Direct] 
Direct | | 
Or BISAM for OSAM | 
Read |Read ! 
or OSAM | | 
Read { | 
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IMS/VS DB BATCH PROCESSING 


| | I 
| DL/I ! DATA BASE ACCESS METHOD 
I Datahatedetetatetetateheatehteheehettae Sala taneSaREaRaatarettatetatnaiaae 
| CALL | HISAM |  HDAM HIDAM 
| ! | 22-22-22 2 -n 2-2 2-2-2 ------ 
| FUNCTION | | | INDEX | #£HIDAM 
| | | 


[ 
VSAM-Get | VSAM-Get 


| { | | ' 
| } VSAM-Get- | {| VSAM-Get | 
| | Skip Seq | Direct | Skip Seq ]} Direct ! 
| GU } or QISAM { or OSAM { or QISAM | or OSAM | 
! |} Get 1 Read } SetL & |} Read | 
| } | | Get \ [ 
| fs SS ee | ee ee | 
| | VSAM-Get- | | VSAM-Get- | ! 
| | Direct | ! Direct | ! 
| { or | [| or | | 
! ! BISAM ! | BISAM | ! 
| j Read * | { Read * | | 
| ! | | | ' 
[SaaS See eae ers a Ser eee eee eee ee en ea ee ee ee ee eee | 
| {| VSAM-Get- | VSAM-Get [| VSAM-Get- {| VSAM-GET | 
j } Skip Seq {| Direct } Skip Seq {| Direct | 
| GN | or QISAM | or OSAM | or QISAM |} or OSAM | 
| ! Get, OSAM ! Read 1! SetL & | Read | 
| { Read | {| Get | | 
' [ie ee ee ee SS Meee ee { 
| VSAM-GET | | VSAM-GET | | 
] | Direct | | Direct | 1 
| | or { or 
| {| BISAM | | BISAM | ' 
| | Read * | } Read * | | 
{ { | [ | 
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* BISAM read or VSAM Get Direct is used if two or more data base PCBs 
are defined in an application program's PSB for one physical data 
base. Random or direct access operation is assumed. QISAM SetL/Get 
or VSAM Skip Sequential is used if one data base PCB per physical data 
base is used. 


It is suggested that, where possible, the GET NEXT call, with or 
without SSAs, be used in preference to the GET UNIQUE call function for 
segment retrieval. This results in more efficient operation. Remember, 
however, that the GET NEXT call function can only be used to progress 
forward in a data structure, and across data structures in a data base. 


PERFORMANCE CONSIDERATIONS 


Using Accumulated DL/I Statistics 
During execution of the batch application program, statistics are 
accumulated by DL/I concerning reading, writing, and buffering activity. 

This information can be utilized to tune the application for higher 
performance. Details for obtaining these statistics are in the IMS/VS 
Application Programming Reference Manual. 
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TELECOMMUNICATION INPUT/OUTPUT INTERFACE 


Design of a TP {(telecommunication) application encompasses the batch 
application program design as well. There is little difference between 
the batch program and the telecommunication program when using IMS/VS. 


Figure 3-6 shows the environment in which the TP application 
functions. This shows DL/I as the interface between telecommunication 
terminals as well as data bases. The application program ina TP 
environment deals exclusively with DL/I for input and output for 
terminals as well as data bases. 


OS/VS 









IMS/VS 
CONTROL 
















| | 
APPLICATION | APPLICATION 
PROGRAM PROGRAM 


DATA 
COMMUNI- 


. CATIONS 






TRANSACTION 
RESPONSE 


DATA 
BASE 


aya fl oe 


Figure 3-6. Telecommunication Application Program Design 


The three areas shown under the operating system each represent 
operating system jobs. Each is under a different storage protection 
key. The job on the left consists of the IMS/VS control program, which 
is responsible for all physical input/output for IMS/VS applications. 
The control program is also responsible for maintaining logical 
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information for restart and recovery purposes. The two application 
programs shown are each contained in a message processing region. Each 
message processing region is an operating system job. This IMS/VS 
control region is responsible for causing the appropriate application 
program to be loaded for processing. 


With IMS/VS, the interface to data bases is unchanged when going from 
a batch application to a TP application. In addition, the same 
interface used for data bases is used for input and output to terminals. 


The application program deals with logical terminals. These are 
control blocks that IMS/VS associates with physical terminals. Thus the 
application programmer generally does not concern himself with the 
physical attributes of the terminal with which he is dealing. Figure 
3-7 shows an application program's view of the terminal. 


The control block with which the application program deals is the TP 
PCB (telecommunication program communication block). There are two 
types of TP PCBs -- the I/O PCB and alternate PCBs. An I/O PCB is 
always provided by IMS/VS to an application program that executes in a 
TP environment. Alternate PCBs are optional, and are created as part of 
the PSB (Program Specification Block). To obtain an input message and 
reply to it, the application program must reference the I/0 PCB. To 
send a reply to a terminal other than the terminal that orginated the 
input message, the program references an alternate PCB. The section 
named "Output to Alternate Destinations" contains a further description 
of alternate PCBs. Figure 3-8 shows a DB PCB (data base progran 
communication block) in addition to the TP PCB. The data base is viewed 
as a logical structure and the terminal is viewed as a logical terminal. 





APPLICATION PROGRAM / 
/ 
/ 
| 
TP LOGICAL 
PCB | TERMINAL 
= \ 
\ 
\ 
\ 
Figure 3-7. Application Program's View of the Terminal 
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APPLICATION PROGRAM 
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\ 
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\ LOGICAL 
DATA BASE 
\ STRUCTURE 
\ 
\ 
Figure 3-8. DB and TP PCBs 


Information received from or sent to a terminal is called a message. 
A message is comprised of one or more segments. Figure 3-9 shows the 
format of a message segment. The L field specifies the length of the 
segment. If line addressing is being used, field Z2 is used for screen 
control when sending output to a 2260 or 2265 Display Station. The Z 
field is followed by the message text. This is the information input at 
the terminal. Below the segment format are shown two examples of input 
-- one with a password and the other without. Notice that the password 
has been eliminated from the text prior to the application program 
receiving it. 


|--> Message segment up to 130 characters 


--> Reserved for DL/I (halfword binary) 


ES om Gee og 22GD ...m 


--> Segment length in bytes including L, Z, and TEXT 
{halfword binary) 


Terminal input segment TRANS (PASSWORD) THIS IS THE 

with password: SEGMENT TEXT 

Received by application: TRANS THIS IS THE SEGMENT TEXT 

Terminal output segment 

without password: TRANS THIS IS THE SEGMENT TEXT 

Received by application: TRANS THIS IS THE SEGMENT TEXT 
Figure 3-9. Message Segment Format 
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Input Calls 


Calls for input message segments are like calls for data base record 
segments, except that no segment search arguments are required. The get 
unigue call is used to obtain the first segment of each message and the J 
get next call is used to obtain subsequent segments. Figure 3-10 shows 
the format of the input call. The three parameters shown being passed 
to DL/I are the function code, the I/O PCB address, and the address of 
an input area. Message A, as shown, consists of three segments, while 
Message B consists of two segments. 


ENTER LINKAGE. COMMENT ONLY 
CALL 'CBLTDLI!' USING IFUN, LTPCB, IMSG-IO-AREA. 
ENTER COBOL. COMMENT ONLY 


MESSAGE A 
Bel A ee eng ee ee, eh ee ee 1 
! FIRST SEGMENT [> <2-ss22Sse5 GET UNIQUE 
_ SECOND SEGMENT = Coe GET NEXT 
! _ THIRD SEGMENT ees GET NEXT 
MESSAGE B 
Be age eee ye et ae Fe ee yee 1 
| FIRST SEGMENT 1 | <SeSss==S= GET UNIQUE 
! a SECOND SEGMENT 20 | eae GED NEXT J 


Figure 3-10. Input Call Format 


Output Calls 


Sending output to a logical terminal is like inserting new segments 
to a data base. As with the input call, no segment search arguments are 
requiredsi Figure 3-11 shows a three-segment message being built. The 
parameters passed in the call to DL/I represent the function code, TP 
PCB, Output area, and message format name. The message format name is 
ignored on systems without the Message Format Service. Format of the 
output message is the same as that of the input message. The 
application programmer must supply the character count. 
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Message X 


a ag ee Pir Flt ag, 2 geo eT ——tq 

| | 

| FIRST SEGMENT | CALL *CBLTDLI* USING OFON, TPPCB, 
| | OMSG-IO-AREA, MSG-FMT. 

[Sateen eeesecstcere seer rer tees | 

| 

| SECOND SEGMENT | CALL 'CBLTDLI* USING OFUN, TPPCB, 
| | OMSG-IO-AREA. 

[Sees age tans eee ! 

| | 

] THIRD SEGMENT i CALL ‘CBLTDLI' USING OFUN, TPPCB, 
] | OMSG-IO-AREA. 

Lew ween we www ww eww www ew ween ew eo J 


Figure 3-11. Three-Segment Message 


OUTPUT TO ALTERNATE DESTINATIONS 


In addition to sending output back to the terminal that generated the 
input, the application program can send output to additional 
destinations. Output can be sent to other logical terminals or to other 
programs. The mechanism for sending to these alternate destinations is 
the alternate PCB, as shown in Figure 3-12. When sending output to 
another program, the receiving program can be a message processing 
program or a batch message processing program. The batch message 
processing program, in addition to making use of online data bases and 
message queues, can utilize operating system data management facilities. 
Use of batch message processing programs is discussed later in this 
chapter. For information on Fast Path use of alternate PCBs see the 
"Fast Path and IMS/VS Interrelationships" section in the chapter "Design 
Considerations for the Fast Path Feature." 
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Figure 3-12. Output to Alternate Destinations 


Modifiable Alternate PCBs 


The modifiable PCB and change call have been provided for those users 
who would otherwise require a prohibitively high number of alternate 
PCBs to allow for all possible destinations. This would, for example, 
be those 1050 or 2780 users with a requirement for an alternate PCB for 
each component assigned to the terminal represented by the I/0 PCB. 
Without this function these users would require as many as four 
alternate PCBs per terminal defined in the system. By providing a 
Naming convention within the IMS/VS system to allow the application 
programmer to identify a group of logical terminals by I/0 PCB name, 
this requirement could be reduced to four modifiable alternate PCBs or 
less. 


For examples If NAME is found to be the I/0 PCB logical terminal 
hame, NAMECP is the logical terminal assigned to the card punch, NAMEPFPT 
is the printer, etc. With this convention the user could add the suffix 
CP to the I/O PCB name to cause output to go to the card punch 
associated with the physical terminal that entered the message, PRT 
would allow the output to go to the printer, etc. This requires that 
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the naming convention be established by system definition and maintained 
by instructing the master terminal operator to reassign component LTERMS 
by groups, so that all the components are always associated with the 
same physical terminal. 


This function could also be used by any application that, depending 
on the processing involved, requires one of many possible output 
destinations. 


The user should define one modifiable PCB per possible destination 
per transaction, as the destination can be set only once per message 
without use of the purge call, which is not recommended. This means 
Simply that the destination cannot be changed once a message segment has 
been inserted to the PCB until a get unique to the I/0 PCB is issued. 


Normal use of the function would therefore be: 


GU I/O PCB 

CHNG Modifiable alternate PCB 
ISRT Modifiable alternate PCB 
GU I/O PCB 

CHNG Modifiable alternate PCB 
etc. 


Response Alternate PCBs 


An alternate PCB can be used to respond to terminals in response 
mode, conversational mode, or exclusive mode, if the PCB is so defined 
on the alternate PCB statement. Use of this response alternate PCB 
allows the application program to send output to a logical terminal that 
did not originate the input message, while still satisfying the 
requirements of these operating modes. This response alternate PCB is 
only valid for naming a logical terminal. 


IMS/VS can also be directed to verify that the logical terminal named 
in the response alternate PCB is assigned to the same physical terminal 
as the logical terminal that originated the input message. This 
verification is required for alternate response PCBs used by 
conversational programs and response mode transactions. Verification is 
not needed if alternate response PCBs are used to send messages to 
output-only devices that are in exclusive mode. Additional information 


CONVERTING FROM BATCH TO TELECOMMU NICATION 


Conversion from batch to online with IMS/VS can be a simple process. 
Figure 3-13 shows a batch application program which deals with DL/I data 
bases. The procedural portion of the application program differs little 
between batch and TP. The DL/I data base I/O calls need not be altered 
at all. The area of conversion will be that portion which deals with 
external input [SYSIN) and output (SYSOUT). The TRANSACTION and 
RESPONSE in the application program shown represent the primary input 
and output. The READ/WRITE or GET/PUT in the batch system are replaced 
by DL/I calls for input and output for telecommunication. Instead of 
the input coming in from SYSIN, it comes from a logical terminal. 
Output, instead of being written to SYSOUT, is written to a logical 
terminal. It can be seen that use of DL/I for transactions and responses 
as well as data base I/0, makes DL/I the single I/0 interface with which 
the application program deals. 


Application Program Design 3.17 





APPLICATION PROGRAM 








FE Oe a a eg te pt Meg ore, ~T 
: PROCEDURE . ) 
| OSs/vs READ 
y, EXTERNAL INPUT/OUTPUT write 
/ | 
/ | DL/I | 
/ | DATA BASE 
/ | INPUT /OUTPUT | 
CONVERTING / DS fa cae etal ge ee eg, A ge Mg Sy eee | ae 
TO TELE- | 
COMMUNICATION , BRA 
| BASE 


‘ DL/I TRANSACTION/ 
RESPONSE 


TELECOMMUNICATION CALL DL/I 
INPUT /OUTPUT 





Figure 3-13. Converting from Batch to Telecommunication 


TELECOMMUNICATION DEVICE INDEPENDENT PROGRAMMING 


If a variety of devices are to be used on an IMS/VS telecommunication 
system, some consideration should be given to designing application 
programs in such a way that input is processed properly regardless of } 
the physical terminal type from which it is received. For example, 
input might be received from either a 2740 or a 3270. The maxinun 
physical line length for a 2740 is 130 characters, and one line of input 
is handled as one message segment. For a 3270, on the other hand, the 
user defines the structure and length of a message segment. 


If I/0 formats are to be consistent between devices with different 
length I/O characteristics, design must be aimed toward the limiting 
device. For example, a 3270 can only accommodate 80 characters on each 
line, while the 2740 can handle 130. A design for a 130-character line 
would not operate identically with the 2740 and the 3270. Another 
approach is to have the application program written so that it can 
determine the class of device with which it is dealing. This can be 
accomplished through the use of naming conventions. For example, the 
first character of each logical terminal associated with an 80 character 
device could begin with the letter V. 


The application program has access to this name at the time the 
message is acquired. 


DEVICE CLASS CONTROL CONSIDERATIONS 


Control characters for control of output devices are the 
responsibility of the application programmer. The 2260, 2265, and the 
2265 component of the 2770 system makes use of the Z field in the 
message format shown earlier, in conjunction with the line addressing 
feature of the 2260/2265 and the paging feature of IMS/VS. On a 2980 
General Banking Terminal Model 1 or Model 4, the Z field of the message 
format is used to direct output message segments to a passbook; on a . 
2980 Model 2 terminal, this field is used to require the presence of the 
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auditor's key, in order to receive an output message segment. Switched 

devices (except 3270) also make use of the Z field in the message format 
shown earlier. This is used by the application program to request that 

the line be disconnected after the present message is sent. This field 

is ignored by communications control if the output is physically sent to 
a device without this capability. 


Carriage return characters, or new line symbols, are embedded in the 
text portion of the message by the application programmer. If output is 
going to a 2770 printer component, 2780, or local printer (SYSOUT) 
device, the first two characters of the message can be carriage control 
characters. These are also the responsibility of the application 
programmer. 


Vocabulary drum address characters may be the text portion (or part 
thereof) of the message going to a 7770-3 line. These are also the 
responsibility of the application programmer. 


Under special conditions, it may be desirable to terminate an output 
message at a specific point. The DL/I purge call with TP PCB address 
can be used to accomplish this function. Figure 3-14 shows two messages 
to the destination being built. 


The purge call releases the output message segments for processing 
without waiting for the application program to signify normal completion 
(by a get unique of the next transaction or normal termination) of the 
current transaction. 


ENTER LINKAGE. COMMENT ONLY 
CALL *CBLTDLI' USING PURG, TPPCB. 
ENTER COBOL. COMMENT ONLY 


Message A{(1) 


! FIRST SEGMENT l, Seseeeses= INSERT 
a SECOND SEGMENT [ eesieeee INSERT 
ro es THIRD SEGMENT yeeeeesees INS ERT 
————————— ; aa ae PURGE 


a FIRST (FOURTH) SEGMENT = i eseceseee eusene 

ov" Sgcoup (Fivts) StceEnt [p penrnane —_ 

| parep (Steray SecuENr F vpn enna 

ee ; K-23-====> GET UNIQUE or program 
termination 

Figure 3-14, Six-Segment Message Separated into Two Three-Segqment 


Messages by Use of the Purge Call 
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UTILIZATION OF SYSOUT DEVICES 


The use of support provided for SYSOUT devices (printers, tape, or 
DASD) allows a wide range of applications, including: 


e Local terminal simulation using a card reader and printer. 


e High volume output, such as reports using either a printer or tape 
volume. 


e Intermediate output to be used by a non-IMS/VS application program 
using either tape or disk volumes. 


Since record formats, logical record lengths, and block sizes are 
user-defined, a SYSOUT data set can have a variety of different 
attributes. 


By using the spool SYSOUT option, a local printer can be simulated 
without dedicating the device to the IMS/VS systen. 


Program Testing Using SYSIN/SYSOUT 

SYSIN data streams can be assigned to a local card reader line, 
providing a means by which nonconversational telecommunication 
application programs can be tested. When such an assignment is made, a 
program can be tested with data entered through SYSIN and output 
produced using any of the optional types of SYSOUT support available. 
Only one file of data can be entered per line. Any logical errors 
detected in processing the data stream (for example, invalid transaction 
codes) are ignored by IMS/VS. Care must be taken to avoid undesirable 
results when this type of error occurs in the first segment of a 
multisegment transaction, since all following segments are processed as 
hew messages. 


When SYSIN data streams are used by IMS/VS, no logging of position 
occurs while messages are being processed. Consequently, only a cold 
Start of IMS/VS operation should be performed after using SYSIN input 
streams, or duplicate message processing may occur. 


CONVERSATIONAL PROCESSING 


Conversational processing is an optional IMS/VS feature available to 
users of the data communications facility. It allows a user's 
application program to retain information acquired through multiple 
interchanges with a terminal, even though the program leaves the message 
region between interchanges. 


If conversational processing is to be used, it must be considered 
during system definition. Transactions that will invoke a 
conversational program must be identified at this time. The user must 
also describe the number and size of the SPAs (scratchpad areas) to be 
allocated, either in main storage or on a direct access device. An SPA 
is used to contain the information to be retained during conversational 
interchanges. 


Figure 3-15 shows a simple conversational process. When IMS/VS 


receives a conversational transaction it assigns an SPA to the input 
terminal and schedules the associated application progran. 
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Figure 3-15. Conversational Progran 


When the program executes and issues its first GU, it receives the 
SPA. The first segment of the message input from the terminal is 
obtained by a GN call. After processing the segment, the program must 
issue an ISRT call to return the SPA to IMS/VS.~ IMS/VS retains the 
scratchpad either in main storage or on disk until needed. The program 
then must use ISRT to send an output message to the terminal in 
conversation. 


A response to the terminal in conversation is required to allow the 
conversation to continue. The conversational transaction need only he 
entered to initiate the conversation; during subsequent interchanges 
IMS/VS considers all input from that terminal to be a part of the 
conversation. 


IMS/VS allows more than one program to participate in a conversation. 
One conversational program passes control to another, either by changing 
the transaction code in the SPA to another conversational transaction, 
or by inserting the SPA to an alternate PCB identifying the program to 
take control of the conversation. 


When a conversation is processed to its normal completion, it is 
terminated by the application program. The program places blanks in the 
transaction code in the SPA before returning it through the ISRT call. 
The program can also put the code of a nonconversational transaction in 
the SPA; the conversation then remains active until the next input is 
received from the terminal. IMS/VS routes this input to the 
nonconversational transaction, thus terminating the conversation. 


IMS/VS terminal commands are valid during a conversation. Commands 
are provided, in fact, to allow the operator to temporarily suspend a 
conversation in progress {/HOLD command) and to resume it at a later 
time (/RELEASE command). The /EXIT command is available for the 
Operator to terminate the conversation. 


Some applications require that a conversational process not be 
interrupted once it has started. This is because non-program initiated 
termination could result in partially-updated data bases. This type of 
termination can occur if the operator prematurely uses the /EXIT 
command, or if a program involved in the conversation abnormally 
terminates. When this condition occurs, a user exit routine can be 
entered to analyze the termination and, if desired, to cause another 
program to be scheduled to complete or backout any data base updates. 
The user exit routine cannot cause the conversation to continue. The 
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IMS/VS System Programming Reference Manual contains specifications for a 


conversation abnormal termination exit routine. 


For information on the Automated Operator Application Program, see 
the “Automated Operator Programming™ chapter, in the IMS/VS Systen 
Programming Reference Manual. 


PAGING FEATURE ~-- 2260 AND 2265 


The paging feature allows an application program to insert a multiple 
screen message to the 2260 or 2265 which can be viewed by the operator 
in any sequence he wishes. If, after viewing the first screen, the 
operator chooses to skip all remaining screens and go to the next 
message, he can. Alternatively, as an example, he can look at the first 
screen, page forward to the 17th screen, page back to the fifth screen, 
view several screens in sequence, etc. He can go to the next message or 
series of screens at any time, whether or not he has looked at all the 
screens in this series. Once this option is taken however, he cannot 
return to look at any image from a previous series. IMS/VS prevents the 
operator from inadvertently paging past the end of one series into 
another, thus losing the current series. 


The operator is supplied with a page-request indicator (=) to specify 
which page is to be viewed next. If Auto Delete was specified in system 
definition, any other input message, that is, one that does not begin 
with a page-request indicator, causes the series of pages being viewed 
to be considered complete and the series to be dequeued. Therefore, 
when an operator has completed viewing a series of pages he has merely 
to enter a new transaction code to signify this to the system. If a 
multiple-page message is routed to a non-paged terminal, such as a 2740, 
the paging is ignored, and the message is transmitted as any other 
message. If Auto Delete was not specified, the operator can enter a 
message while viewing a page. This causes the first page of the series 
to b2 redisplayed, and the operator must specifically enter a 
next-output indicator (7) to cause the series of pages to be dequeued. 
While this mode of operation may have merit in specific applications, it 
may prove cumbersome to the operator in a generalized system 
application. It is recommended, therefore, that the user be aware of the 
operational procedures required for non-Auto Delete operation before 
specifying this mode of operation. 


BATCH MESSAGE PROCESSING PROGRAMS 


While the IMS/VS telecommunication system is in operation, it may be 
desirable to let a batch program have access to online data bases or 
input/output message queues. This can be accomplished by a batch 
message processing program (BMP). This program is loaded in the 
conventional operating system manner. It has access to online data 
bases and message queues, and can also make use of operating system data 
management facilities. 


When starting a BMP, several parameters may be specified on the EXEC 
statement. These include the PSB and program name. For message 
processing programs, the PSB and program name must be the same; however, 
they can be different for BMPs. This allows a utility program to be run 
using different PSBs. 


BMP can implement a checkpoint to purge data base and message 
buffers. It writes a checkpoint ID to the system log. This checkpoint 
is independent of CTL (control region) and other BMP region checkpoints. 
IMS/VS maintains a checkpoint table to correlate BMP checkpoints with 
control region checkpoints for purposes of emergency restart. Design 
considerations for using this checkpoint table are contained in 
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Application Programming Reference Manual contains a description of the 


checkpoint (CHKP) call. 


Emergency restart after a system failure backs out all resources for 
each BMP region to the last checkpoint for that BMP region. The master 
terminal operator has the option of specifying that BMP data base 
changes NOT be backed out at emergency restart. 


If there is no backout for a BMP, the operator also has the option of 
releasing the resources that were reserved for the BMP (that is, 
starting stopped data bases). If backout has been done, the resources 
are not reserved since data base integrity has been maintained. 


USE OF BMP 


The BMP is useful for several types of processing. If data is being 
collected for batch processing, the message processing program can 
retrieve the collected data from the queue. Upon a single loading, a 
BMP can deal with only one input queve (transaction code). The 
transaction code is also specified on the EXEC statement when the BMP is 
started. The BMP sends output to logical terminals or other programs 
through the queues. The BMP is useful for doing summary reports while 
the data bases are being utilized in a telecommunication environment. 
Use of the BMP to update data bases, while the online system is in 
Operation, can prevent message regions from being scheduled when (1) the 
MPP and BMP use the same data base and that data base was not specified 
for parallel scheduling, or (2) when PROCOPT=EXCLUSIVE is specified. 
Note also that BMPs that do not issue a checkpoint call may cause 
excessive waiting or deadlocks for MPPs accessing the same data base. 


BUFFERING 


Heavy utilization of data base buffers by a BMP can impact response 
time at a terminal, if a relatively small data base buffer pool is 
allocated. Since the pool is utilized for all data bases, and the oldest 
buffer is always freed for current I/O requests, additional I/0 requests 
may be required for those telecommunication programs performing data 
base updates. It is possible that a message processing program may 
obtain a segment for update, and prior to the REPLACE call have the 
buffer containing the segment may be freed. DL/I must then reread the 
segment for replacement. 


USEFUL TECHNIQUES 


INTERMEDIATE DATA BASES 


If the user wants to save information between loads of an application 
program, without making use of the conversational capability, 
intermediate data bases can be utilized. Figure 3-16 shows an 
intermediate data base being utilized for purchase order writing. Each 
logical terminal is represented by a root key in the data base. Since 
all logical terminal names are unique, there is no possibility of 
conflicts between terminals. The application program has access to the 
source of each input through the input/output logical terminal PCB. 
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Figure 3-16. Intermediate Data Base 


MESSAGE EDITING 


If free form input is allowed from input terminals, a single message 
editing routine is an alternative to redundant code in the COBOL or PL/I 
program. The message editing routine can convert the message from a 
free format into a fixed format. 


The edit routine can be located in the IMS/VS control region or in 
the message processing region with the application program. If an edit 
routine is to be used a great deal, it should be included in the IMS/VS 
control region. In some instances this helps reduce the region size 
required for the message processing region. 


If the edit routine is to be included in the message processing 
region as a part of the application program, the possibility of placing 
the module in link pack should be explored. 


Use of a single message edit routine for ail programs could have 
value for some user environments. The message edit routine could be the 
only user module making calls on DL/I for message input/output. This 
could reduce the amount of error checking required in each application 
program. 


OUTPUTTING A MASK TO THE 2260 


When a 2260 is being used in an interactive manner, terminal operator 
time can be saved by having the application program send out a mask or 
form to the 2260. The terminal operator then fills in the appropriate 
information and transmits the entire screen as input. 


PASSING INFORMATION FROM ONE PROGRAM TO ANOTHER 


When a program is to be designed in a modular fashion, there are 
several ways in which information can be passed from one program to 
another. The first way is by sending output to an alternate destination 
through the queues. Another is to store information in an intermediate 
data base, as discussed earlier. A third way is to use a scratchpad 
area for passing the information from one program to another. If the 
scratchpad area is resident in storage, the input/output overhead is 
less than by the other approaches. 
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The data management portion of IMS/VS is designed to simplify the 
task of assembling and maintaining large amounts of data while still 
offering flexibility in how the data is organized and used. To 
accomplish this, IMS/VS uses an organization for data called a data 
base. 


Under IMS/VS, different types of data bases can be created by the 
user. Each requires two definitions before the data base can be used by 
application programs. The user defines the data base structure and 
content through Data Bas2 Description Generation (DBDGEN). He also 
defines what data within the data base each application program will 
use, and what processing options each application program is allowed to 
use on that data through Program Specification Block Generation 
(PSBGEN). Each of the data base types is supported by and named after 
its own access method. The access methods and the data base type each 
is used for are: 


Access Method Data Base Type 
e Hierarchic Sequential Access Method (HSAM) HSAM 
e Hierarchic Indexed Sequential Access 
Method (HISAM) HISAM 
e Hierarchic Direct Access Method (HDAM) HDAM 
e Hierarchic Indexed Direct Access 
Method (HIDAM) HIDAM 
e Logical Logical 
e Generalized Sequential Access Method (GSAM) GSAM 
e Main Storage Data Base MSDB 
e Direct Entry Data Base DEDB 


For information on the Main Storage Data Base (MSDB) and the Data 
Entry Data Base (DEDB) see the "Fast Path Data Bases" section in the 
chapter "Design Considerations for the Fast Path Feature." 


A logical data base is comprised of data stored in one or more 
physical data bases that is structured logically to satisfy the 
requirements of an application program. 


GSAM data bases are limited to a single, unstructured data set. 


Prior to discussing the advantages and disadvantages of each type of 
data base, the concepts and terms used for IMS/VS data bases must be 
understood. 


CONCEPTS OF PHYSICAL DATA BASES 
In general, an IMS/VS data base is a hierarchic organization of the 
different types of data required by one or more applications. We'll 
examine first its content and structure, and we'll then describe the 
DL/I calls that are used to process a data base. Included in content 
are segments and fields. Structure includes the definition of the 
hierarchy of a physical data base. Note that GSAM data bases are not 
hierarchic and are based on physical records rather than segments. 
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SEGMENTS 


A data base is a storage organization that enables the user to manage | 
multiple sets of data, and multiple elements of each set. The content ) 
of a data base is defined by segment type through the DBDGEN utility. 

For each set of data the user wants to store in a data base, he defines 
a segment type and the physical characteristics to use when storing 
segments of that type. In turn, when multiple elements of data of a set 
are stored in a data base, they are stored as segments of the type 
defined and use the physical characteristics defined for that seqment 
type. A segment in a data base is also called an occurrence. Both 
terms are used interchangeably to refer to a segment. A data base can 
contain a maximum of 255 segment types, and the number of segments of 
any type defined is limited only by the space allocated for the data 
base. 


The input to DBDGEN that defines a segment type and the physical 
characteristics of that segment type is the SEGM statement. Among the 
physical characteristics defined for each segment type are the name, 
length, and hierarchic position to be used when storing segments of that 
type. The name specified is used to identify segments of that type in 
storage, and in turn, the application program uses the name of a segment 
type to address the type of segment to be processed. The length 
specified for a segment type tells IMS/VS the number of bytes of 
auxiliary storage to use for the data portion of each segment of that 
type. For the segments in storage that contain a prefix and data 
portion, the prefix is used by IMS/VS in managing the segment, and the 
data portion of the segment contains the user data. The length 
specified for the data portion of a segment type must be fixed, except 
when VSAM is used as the operating system access method. When VSAM is 
used, the length specified for the data portion of a segment type can be 
either fixed or variable. When variable length is specified, the amount 
of auxiliary storage space used for the data portion of each segment of . 
that type can vary between a user specified minimum and maximum number ; 
of bytes. In the case of fixed, the data portion of each segment of the 
same type occupies the same amount of auxiliary storage space. The 
length specified for a segment type cannot exceed the physical record 
length of the storage device used. The hierarchic position defined for 
a segment type determines how segments of that type are stored ina data 
base in relation to segments of other types. For an explanation of the 
hierarchic position of a segment type in a physical data base, refer to 
"structure" in this chapter. 


SEGMENT FORMATS 


When defining a segment type, the segment length specified by the 
user can be either fixed or variable. In either case, segments in 
IMS/VS data bases contain a prefix and a data portion except for three 
cases where only the data portion is present. For an HSAM, simple HSAM 
or simple HISAM data base that contains only one segment type, no prefix 
is stored with occurrences of the segment type in the data hbase. 


The fixed and variable length format for segments in HSAM, HISAM, 
HDAM and HIDAM data bases are shown in Figure 4-1. 
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Fixed length segment format 


| PREFIX | DATA | 


FIXED LENGTH 
USER DATA 


Variable length segment format 














POINTER AND COUNTER 
AREA 


| PREFIX DATA 
SEGMENT | DELETE 
CODE BYTE 


Pigure 4-1. Segment Formats 












POINTER AND COUNTER 
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VARIABLE LENGTH 
USER DATA 





Segments in all data base types contain a prefix and data portion 
except in the 3 cases stated previously. The prefix of a segment 
contains data used by IMS/VS that is transparent to application 
programs. The data portion of a segment contains user data. AS a 
minimum, the prefix of a segment contains a segment code and a delete 
byte. The content of the remaining portion of the prefix varies by data 
base type. Segments are related through direct address pointers in HDAM 
and HIDAM data bases, so all segments in those data bases will contain 
One or more pointers in their prefix. Segments in HSAM and HISAM data 
bases are related through physical adjacency so they will have no direct 
address pointers in their prefix. The one exception to this is a 
segment in a HISAM data base that is involved in a logical relationship 
with a segment in an HDAM or HIDAM data base. When the segment in the 
HISAM data base points to the segment in the HDAM or HIDAM data base, it 
can have a direct address pointer specified to point to the HDAM or 
HIDAM segment directly. A counter is only present in the prefix of a 
segment under certain conditions when it is involved in a logical 
relationship. For the conditions under which the counter will be 
present in a prefix and the use of the counter, see "Pointers and the 
Counter Used in Logical Relationships" in this chapter. 


Seqment Code 


To identify each segment stored in an IMS/VS data base, a one byte 
segment code is placed in the first byte of the prefix of the segment. 
The segment code is a number from 1 to 255 that identifies a segment 
type to IMS/VS in place of its name. Segment code values are assigned 
to the segment types in a data base in ascending sequence starting with 
the root segment type and then continuing to all dependent segment types 
following the hierarchic sequence defined for the segment types in a 
data base by the user. 


The delete byte is used by IMS/VS to maintain the delete status of 
segments within a data base. The meaning of each bit within the delete 
byte is shown in Figure 4-2. 
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DELETE BYTE 
BIT MEANING 
0 SEGMENT HAS BEEN DELETED (HISAM OR INDEX ONLY) 
I DATA BASE RECORD HAS BEEN DELETED (HISAM OR INDEX ONLY) 
2 SEGMENT PROCESSED BY DELETE 
3 RESERVED 
4 DATA AND PREFIX ARE SEPARATED IN STORAGE 
5 SEGMENT DELETED FROM PHYSICAL PATH 


(PHYSICAL DELETE (PD) BIT) 


6 SEGMENT DELETED FROM LOGICAL PATH 
(LOGICAL DELETE (LD) BIT) 


7 SEGMENT HAS BEEN REMOVED FROM ITS LT CHAIN 
(BIT 7 IS ASSUMED SET IF BITS 5 AND 6 ARE SET) 


Figure 4-2. Delete Byte 


FIELDS 


An application program addresses segments in a data base through the 
hame specified for their segment type, and through the names of fields 
defined within a segment type. The segment name alone allows an 
application program to address a specific segment type within a data 
base. To address a specific occurrence of a segment type, fields must 
be defined within that segment type. 


Within the data portion of each segment type, the user can define 
fields through the DBDGEN utility. Each is defined through a FIELD 
statement which is input to DBDGEN. The maximum number of fields that 
can be defined within a segment type is 255 and the maximum within a 
data base is 1000. The two types of fields that can be defined are 
sequence fields and data fields. Both fields can be used by an 
application program to address specific segments in a data base. A 
seguence field, often referred to as a key field, has two purposes in 
addition to that of the data field. It is used to store occurrences of 
a segment typ2 in a sequential order. The order is determined by the 
value placed in the sequence field of each occurrence. The value in the 
sequence field of a segment is called the key of that segment. 
Occurrences of a segment type are stored in ascending order in the data 
base starting with the occurrence that contains the lowest sequence 
field key. The sequence field is also used as all or part of a symbolic 
pointer to a segment in a data base. The symbolic pointer is actually 
the concatenation of the keys in the sequence fields of all segments 
that must be retrieved to reach the desired segment including the 
sequence field key of the desired segment as shown in Figure 4-3. 


Only one sequence field can be defined in each segment type. 
Sequence fields can be defined as unique or non-unique by the user. 
When defined as unigue, occurrences of a segment type must contain 
sequence field values that uniquely identify them within a data base, 
and segments are stored in the data base in the manner described 
previously. When defined as non-unique, sequence field values do not 
have to uniquely identify a segment within a data base. In this case, 
segment occurrences are still sequenced according to their sequence 
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field value which controls all segments except those with the same 
value. If placement of those with the same value is of concern, the user 
must control their placement either through his data base load progran, 
or through the combination of his load program and by stating insert 
rules for segment placement through DBDGEN. 
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Figure 4-3. Concatenated Keys 
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STRUCTURE 


The hierarchy of a data base is created by defining an order of 
dependence for the segment types it contains. To IMS/VS, the hierarchy J 
represents the order in which the user wants his application data 
stored. To the application program, it represents the order in which 
the segment types in a data base are available for processing. The 
criteria normally used in determining the hierarchy is how the data in 
one segment type relates to data in another segment type, and the 
frequency in which a segment type will be accessed by an application 
prog ran. 


To understand how a data base hierarchy is developed, we'll use as an 
example a skills inventory application. We'll determine what segment 
types a data base should contain for the application and the hierarchic 
order of those segment types. In addition, we'll show the data hbase 
that ceuld result in storage by defining the segment types and their 
hierarchic order through the DBDGEN utility. 


Let's assume in our example that an application program wants to 
locate a given skill, and then find out what employees possess that 
Skill. In addition, the application must have access to the experience 
and education records of each employee. 


In the assumptions, four sets of data were required by the skills 
inventory application. Each will be defined as a segment type in our 
skills inventory data base. Let's now create a hierarchic data 
structure that reflects the order in which the four segment types are 
required by the application. To do this, we must determine both the 
order in which the application program must use each type of data, and 
the order in which each type of data must be presented to the 
application program so that the data retains its meaning. In the 
assumptions, it was stated that the application wanted to find a given | 
skill and then find the names of the employees that possessed that 
skill. From this statement we know that skill should be the first type J 
ef data in our structure and that name should follow skill. For the 
remaining types of data, experience and education, no indication was 
given as to how they should fit in our structure, but we can determine 
their position in the structure if we can establish how they should 
relate to the skill and name types of data. For our application, 
experience and education data have no meaning by themselves, to each 
other or in relation to skill. When related to name data however, the 
experience and education types of data do have meaning since they are 
the experience and education records of specific employees. We can now 
complete our data structure. At the top is skill, below skill is name, 
and name in turn is followed by experience and education as shown in 
Figure 4-W. Experience and education are below name since they are 
dependent on name for the skills inventory application. An employees 
name must be established before his experience and education records 
have meaning. In turn, name is dependent on skill since the application 
will locate a given skill and then associate employee names to that 
skill. In summary, the data structure shown in Figure 5.4 represents 
the sets of data and the order of dependence for those sets required by 
the skills inventory application. It contains four sets of data 
arranged in three levels of dependence. An IMS/VS data base can contain 
&@ Maximum of 255 sets of data arranged in up to 15 levels of dependence. 
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EXPERIENCE EDUCATION 





Figure 4-4, Hierarchy of Segment Types 


The data structure just created is called a hierarchy of segment 
types. It represents the segment types and the hierarchic arrangement of 
those segment types that would be defined through DBDGEN to define our 
skills inventory data base. If we now assume data for each segment 


type, Figure 4-5 shows the data base that would result in storage. 


Figure 4-5 shows how segments of each type can be loaded in a data 
base. Three occurrences of the skill segment type are shown. Related 
to each are the specific occurrences of the Name segment type that 
contain the names of the employees who possess that particular skill. 
Related to each Name segment in turn, are the specific segments of the 
Experience and Education segment types that contain the experience and 
education records of each employee. Skill is the root segment type in 
this data base, and each data base has only one. The root segment type 
is always the first segment type defined in a data base, and, as shown, 
it is the only segment type that occupies the first level of a data base 
hierarchy. Segments of all other types in a data base are stored in 
relation to an occurrence of the root, and as such are termed dependents 
of the root. In addition, occurrences of the Experience and Fducation 
segment types, shown at the third level of the hierarchy, are dependents 
of the Name segment type since they are stored in relation to 
occurrences of the Name segment type. When a data base hierarchy is 
read from top to bottom with the root at the top, each lower level in 
the hierarchy contains the dependent segments of the segments at the 
next higher level. Before any dependent segment is loaded in a data 
base, the segments on which it is dependent must be loaded. In all 
cases, a dependent segment in a data base is dependent on one segment at 
each higher level in the hierarchy. 


The major unit of organization for segments within a data base is the 
data base record. A data base is comprised of one or more data hase 
records, and a data base record contains one occurrence of the root 
segment type and all of its dependents arranged in hierarchic sequence. 
Hierarchic seguence for the segments in a data base record is top to 
bottom, then left to right passing through each segment only once. The 
skills inventory data base shown in Figure 4-5 contains three data base 
records, and the hierarchic sequence of each is shown. 
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The hierarchy of a physical or logical data base can contain a 
maximum of 15 levels. The order of dependence for segment types in the 
hierarchy is from level one, or the top of the hierarchy, to level 15, 
the bottom of the hierarchy. The top level of the hierarchy of any data 
base can contain only one segment type. It is called the root segment 
type for that data base. Subsequent levels below the root can contain 
any number of segment types such that the maximum of 255 total segment 
types in the data base is not exceeded. 


Defining a Physical Data Base Hierarchy 

The input to the DBDGEN utility that defines the segment types a data 
base contains, their physical characteristics and their hierarchic 
position is the SEGM statement. (The SEGM statement is described in the 
IMS/VS Utilities Reference Manual.) For our explanation here, it is only 
necessary to know that a data base hierarchy is defined through the 
Order in which SEGM statements are arranged for input to DBDGEN, and 
through use of the PARENT= operand of the SEGM statement. 


The PARENT= operand of the SEGM statement is used to define the 
physical relationships that exist between the segment types on each two 
adjacent levels in a data base hierarchy. The two segment types 
involved in the relationships are called a physical parent and a 
physical child. A physical parent is a segment type that has a 
dependent segment type defined at the next lower level in the data base 
hierarchy. A physical child is a segment type that is dependent on a 
segment type defined at the next higher level in the data base 
hierarchy. These two terms are used to state the order of dependence 
for the segment types in a data base. In a data base with multiple 
segment types defined, the root segment type is the physical parent of 
all segment types defined at the second level of the data base. In 
turn, the segment types on the second level are physical children of the 
root. Each level of a data base contains the physical parent segment 
types of any segment types defined at the next lower level, and the 
physical child segment types of any segment types defined at the next 
higher level. The PARENT= operand of the SEGM statement is used to 
state specifically which segment type at the next higher level is the 
physical parent of a physical child. All segment types in a data hbase, 
except the root, are physical children since each is dependent on at 
least the root. On the SEGM statement that defines each physical child, 
the PARENT= operand is used to specify the name of the physical parent 
segment type. 


The PARENT= operand of the SEGM statement defines the top to botton 
order of segment types. The arrangement of SEGM statements for input to 
the DBDGEN utility defines the left to right arrangement of segment 
types. For input to DBDGEN, SEGM statements must be arranged in 
hierarchic sequence. Hierarchic seguence is defined as top to botton, 
then left to right passing through each segment type only once. The 
seqment types in the hierarchic structure shown in Figure 4-6 are 
numbered to show the order in which SEGM statements to define that 
structure must be arranged for DBDGEN input. 
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Figure 4-6. Segment Types Numbered in Hierarchic Sequence 


Previously, the terms physical parent and physical child were 
defined. The remaining term used to describe physical relationships is 
physical twin. Physical twins are occurrences of the same segment type 
that are dependent on the same occurrence of the physical parent segment 
type. In Figure 4-7, the three Name segments Adams, Jones and Smith are 
physical twins since all three are dependent on the skill segment that 
contains the data artist. Under Adams, the three Experience segments 
are physical twins and the three Education segments are physical twins 
Since, in each case, the three are of the same segment type under the 
Same occurrence of the physical parent segment type. 


The term sibling, used frequently in data base literature, refers to 
the relationship between two or more segment types at the same level 
that are dependents of the same parent type segment. 


The hierarchies of all four physical data base types are defined as 
just described, but in auxiliary storage, each of the four physical data 
base types is organized differently. To understand the advantages of 
one data base organization over another, a basic understanding of the 
DL/I calls used to process segments in a data base is required, since 
the primary trade off between the four types is auxiliary storage space 
versus the performance of application programs processing a data base 
through DL/I calls. 
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CALLS 


The segments in an IMS/VS data base are processed through calls 
issued by an application program. Calls are issued to get, insert, 
delete or replace a segment or a path of segments at a time. A call 
references a parameter list which includes all data required by IMS/VS 
to complete the call. Included in the list are a function code and an 
SSA (segment search argument). The function code states the call to he 
performed, and the SSA states the segment or path of segments to be 
processed. A call is unqualified when no SSA is included with the call, 
and a call is qualified when an SSA is provided for the call. A brief 
description of the primary calls used in processing a data base and a 
brief description of SSAs follows. For more detailed information, refer 
to the IMS/VS Application Programming Reference Manual. 

The direction of movement in a data base is called forward when the 
search for a given segment is going away from the first occurrence of 
the root stored in a data base towards the last segment stored in the 
data base. Backward movement is movement in the opposite direction. 
Position in a data base is the segment or segments in a data base from 
which the search for another segment starts. 


Get Unique 


The GU (get unigue) call is used to retrieve a specific segment or 
path of segments from a data base, and at the same time establishes a 
position in a data base from which additional segments can be processed 
in a forward direction. 


Get Next 

The GN (get next) call is used to retrieve the next desired segment 
Or path of segments from a data base. The get next call normally moves 
forward in the hierarchy of a data base from current position. It can 
be modified to start at an earlier position than current position in the 
data base through a command code, but its normal function is to move 
forward from a given segment to the next desired segment in a data base. 


Get Next within Parent 


The GNP (get next within parent) call is used to retrieve dependent 
segments of a given parent segment from a data base. A get unique or 
get next call is used to establish parentage for the get next within 
parent. After a get unique or get next retrieves a given parent 
segment, successive get next within parent calls retrieve the dependent 
segments of that parent in hierarchic sequence. 


Hold Form of Get Calls 


Another form of the three get calls is the hold form. A GHU [get 
hold unique), GHN (get hold next), or GHNP (get hold next within parent) 
indicates the intent of the user to issue a subsequent delete or replace 
call. A get hold call must be issued before issuing a delete or replace 
call. 


The ISRT {insert) call is used to insert a segment or a path of 
segments into a data base. It is used to initially load segments in all 
data base types, and to add segments to existing HISAM, HDAM and HIDAM 
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data bases. Segments can not be inserted or added into an HSAM data 
base except at load time. 


To control where occurrences of a segment type are inserted into a 
data base, the user can define a unique sequence field in the segment 
type, or specify insert rules that control placement of occurrences of a 
segment type that has no sequence field or a non unique sequence field 
defined. When a unique sequence field is defined in a root segment 
type, the sequence field of each occurrence of the root segment type 
must contain a unigue value. When defined for a dependent segment type, 
the sequence field of each occurrence under a given physical parent must 
contain a unigue value. 


Following are the insert rules the user can specify to control the 
placement of segments in a data base. They are used to control the 
placement of occurrences of a segment type with non-unique sequence 
field values and for placement of all occurrences of a segment type when 
no sequence field has been defined. 


FIRST - States that a new occurrence of a segment type is 
inserted before the first existing occurrence of this 
segment type. If this segment has a non-unique key, a 
new occcurrence is inserted before all existing 
occurrences of the same type that contain the same 
sequence field key. 


LAST - States that a new occurrence is inserted after the last 
existing occurrence of this segment type. If this 
segment has a non-unique key, a new occurrence is 
inserted after all existing occurrences of the same type 
that contain the same sequence field key. 


HERE - Assumes the user has established position on the 
specified segment type by a previous Data Language/I call 
and the new occurrence is inserted before the segment 
which satisfied the last call. If current position is 
not within occurrences of the segment typ? being 
inserted, the new occurrence is inserted before all 
existing occurrences of that segment type. If this 
segment has a non-unique key and data base position is 
not within occurrences of the segment type with 
equivalent key value, a new occurrence is inserted before 
all existing occurrences that contain the same sequence 
field key. 


Delete 


The DLET {delete) call is used to delete a segment or path of 
segnents from a data base. It should be noted that, due to the 
hierarchic arrangement of segments in a data base, the deletion of a 
parent segment implies the deletion of that parent's dependents. When a 
parent segment is deleted in an IMS/VS data base, all of its dependents 
are deleted. 


The REPL {replace) call is used to replace the data in the data 
portion of a segment or path of segments ina data base. 
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SSA (Seqment Search Argument) 
An SSA identifies a segment or group of segments that are to be ’ 

processed by a call. An SSA can contain three parts. As a minimum, it 3 

contains the name of the segment type to be processed. Optionally, an 

SSA can contain command codes and/or qualification statements. Command 

codes, when used, specify a functional variation of a call. 

Qualification statements identify through fields which segment or 

segments of the specified segment type are to be processed by the call. 

A qualification statement contains a field name, relational operator and 

comparative value. When occurrences of the segment type are searched, 

the specified field is compared to the comparative value in accordance 

to the relational operator specified. 


PHYSICAL DATA BASE ORGANIZATION IN STORAGE 


HIERARCHIC SEQUENTIAL AND DIRECT METHODS OF STORING A DATA BASE 


Two storage organization methods are used to create the hierarchic 
arrangement of segments in storage for the four physical data base 
types. The hierarchic sequential method is used for HSAM and HISAM data 
bases, and the hierarchic direct method is used for HDAM and HIDAM data 
bases. The hierarchic sequential method consists of using physically 
adjacent storage locations to store all segments within a data base 
record in hierarchic seguence. This creates a hierarchy for the 
occurrence of the root and all of its dependents within each data base 
record in which each segment is related to the segment that 
hierarchically follows it through physical adjacency in storage. The 
hierarchic direct method consists of placing four byte direct address 
pointers in the prefix of each segment stored in the data base to 
establish the hierarchy of segments in each data base record. 

A description of the types of pointers used in HDAM and HIDAM data j 
bases follows. 


Pointers 

To relate each segment in an HDAM or HIDAM data base to its related 
segments, direct address pointers are used. The pointers are four bytes 
long, and they are placed in the prefix of each segment stored in the 
data base. A direct address pointer consists of the relative byte 
address of a segment from the beginning of a data set. Either one of 
two methods of direct address pointing can be specified for each segment 
type in an HDAM or HIDAM data base. The two methods are hierarchic 
pointing, or the combination of physical child/physical twin pointing. 
Figure 4-8 should be referred to when reading the following descriptions 
of the types of pointers. 
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Two options for hierarchic pointing can be specified for each segment 
type in an HDAM or HIDAM data base. They are hierarchic forward, or 
hierarchic forward and backward pointing. When hierarchic forward 
pointers are specified for all segment types in a data base, each 
segment in a data base record points to the segment that hierarchically 
Follows it through a four byte hierarchic forward pointer. When forward 
and backward pointers are specified, the backward pointer points from 
each segment in a data base record to the segment that hierarchically 
precedes it. The use of hierarchic pointers in an HDAM or HIDAM data 
base results in the same arrangement of segments within each data base 
record as the hierarchic sequential method provides in an HSAM or HISAN 
data base, but rather than segments being related through physical 
adjacency, they are related through pointers that require additional 
auxiliary storage space. For most data bases with high update activity, 
the additional auxiliary storage space used for pointers is more than 
compensated for through the space reuse facilities gained in HDAM and 
HIDAM data bases. 


In a data base that contains hierarchic pointers, when a call is 
issued to process a segment in the data base, the hierarchic forward 
pointers are followed in searching for the segment to be processed. 
Hierarchic backward pointers are used only when a segment is being 
deleted. For delete, the backward pointers improve performance by 
enabling the pointers in the segments that hierarchically precede and 
follow the segment to be deleted to be updated without first going to 
the physical parent of the segment being deleted. With forward only 
pointers, deletion of a dependent segment requires going to the physical 
parent of the dependent, and then searching forward to update the 
pointer in the segment that precedes the segment being deleted as shown 
in Figure 4-9, 


Physical Child/Physical Iwin Pointers 


Physical child/physical twin pointers benefit applications that 
process the segment types in a data base randomly. They allow th2 most 
direct paths to the dependent segment types in a data base. Two options 
for physical child and/or physical twin pointers can be specified for 
each segment type in a data base. The physical child pointers that can 
be specified are physical child first, or both physical child first and 
last. The physical twin pointers that can be specified are physical 
twin forward, or both physical twin forward and backward. When 
specified for all physical child segment types, physical child pointers 
are stored in the prefix of each physical parent segment, and they point 
to each of the physical child segment types of that physical parent 
segment. A physical child first pointer points from a physical parent 
segment to the first occurrence of a physical child segment type in a 
data base that is a dependent of that physical parent. A physical child 
last pointer points from a physical parent segment to the last 
occurrence of a physical child segment type in a data base that is a 
dependent of that physical parent. If a physical parent segment has 
multiple physical child segment types, its prefix contains physical 
child first, or first and last pointers to each of those physical child 
segment types. Physical twin pointers are used to relate all 
occurrences of the same physical child segment type that are dependents 
of the same physical parent segment. Physical twins are multiple 
occurrences of the same segment type that are dependent on one 
occurrence of a physical parent segment type. A physical twin forward 
pointer points from a given twin to the twin following it in the data 
base, and a physical twin backward pointer points from a given twin to 
the twin before it in the data base. 
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‘ese 


Delete segment B4: 








Enter B4 to delete B4: 
(1) Place pointer to BS that is in B4 in work area. 
(2) Goup to Al. 
(3) Follow pointers forward to B3. 


(4) Replace pointer to B4 that is in B3 with pointer to BS from 
work area. 


(5) Delete B4. 


Enter B4 to delete B4: 
(1) Place Forward & Backward pointers that are in B4 in work area. 
(2) Follow backward pointer to B3. 
(3) Replace pointer to B4 that is in B3 with pointer to BS from work 
area. 
(4) Follow Forward pointer to BS. 


(5) Replace pointer to B4 that is in BS with pointer to B3 from work 
area. 


(6) Delete B4. 


Figure 4-9. Nse of Backward Pointers for Delete 


In searching for a given segment in a physical data base using 
physical child/physical twin pointers, the physical child first and 
physical twin forward pointers state the hierarchic path to be followed 
in search of the segment. The normal path followed in locating a 
desired segment is from a given physical parent segment to the first 
occurrence of one of its physical child segment types, and then forward 
through all occurrences of that segment type to the last occurrence 
following physical twin forward pointers. 


A physical child last pointer enables a search to go directly from a 
physical parent to the last occurrence of one of its physical child 
segment types as shown in Figure 4-10. In so doing, the physical child 
last pointer eliminates the forward search of all occurrences of a 
segment type under one physical parent when only the last occurrence of 
the physical child is desired. A physical child last pointer is used 
when inserting a new segment with no sequence field and the insert rule 
specified is last, or for get or insert, when command code L is 
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specified for the call and the SSA for the call has no qualification 
statement. When a physical child last pointer is followed to the last 
Occurrence of a dependent segment, any further movement in the data base 
is forward. A physical child last pointer does not enable searching 
from the last to the first occurrence of a dependent segment under one 
physical parent segment. 





Physical child last pointer eliminates 
the need for a forward search of all 
occurrences stored before the last 
occurrence 


Figure 4-10. Use of Physical Child Last Pointer 


Physical twin backward pointers in dependent segment types are used 
to improve delete performance as described for hierarchic backward 
pointers. In addition, when physical twin forward and backward pointers 
are specified for the root segment type of a HIDAM data base, they 
enable sequential processing across data base records without 
intervening references to the HIDAM index. When only physical twin 
forward pointers are specified for the root segment type of a HIDAM data 
base, sequential processing across data base records requires 
intervening references to the HIDAM index. 


DATA SET GROUPS 


To describe what data sets are used for storing the segment types in 
a data base, and to describe the physical characteristics of those data 
sets, data set groups are defined through the DBDGEN utility using 
DATASET statements. For an HSAM data base, one data set group is 
defined. For HISAM, HDAM and HIDAM data bases, from one to 10 data set 
groups can be defined. The terms used to describe data set groups are 
primary and secondary. A primary data set group contains the root 
segment type. All other data set groups. are called secondary data set 
groups. A primary data set group must be defined for each data base 
type. A secondary data set group is normally defined to enable using 
data sets with different logical record and control interval or block 
lengths to enhance auxiliary storage space utilization. In a HISAM data 
base, a secondary data set group offers one additional advantage. It 
enables direct access to a segment type at the second level of a HISAM 
data base without first accessing a root. 
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Rujes for Dividing a Data Base into Data Set Groups 


HISAM, HDAM and HIDAM data bases can be divided into a maximum of 10 
data set groups according to the rules that follow. 


For HISAM data bases, secondary data set groups cannot be defined 
when VSAM is used as the OS/VS access method for the data base, or when 
a HISAM data base is indexed by a secondary index. HISAM data bases 
using ISAM/OSAM as the OS/VS access methods and not indexed by a 
secondary index can only be divided into multiple data set groups at the 
second level of its hierarchy. The first segment type defined in a 
secondary data set group must be a segment type defined at the second 
level of the hierarchy of a HISAM data base. Included in a secondary 
data set group, are all segment types dependent on the first segment 
type defined in that secondary data set group. 


For HDAM or HIDAM data bases, secondary data set groups can be 
started with a segment type defined at any level of the hierarchy and 
the secondary data set group can contain any combination of the segment 
types in the data base. However, the following restriction must be met. 
A physical parent and its physical children must be connected by PC/PT 
pointers when they are in different data set groups; a PC/PT pointer 
means that each parent must be a physical child [(PC) pointer to the 
first occurrence of each child type, and that the children must be 
connected to each other by physical twin (PT) pointers. 


HSAM STORAGE ORGANIZATION 


In an HSAM data base, all data base records within a data base, as 
well as all segments within each data base record are related through 
physical adjacency in storage as shown in Figure 4-11. An HSAM data 
base is stored on a tape, or a direct access storage device as a 
sequential data set. The data set is loaded in chronological sequence 
and it uses a fixed length unblocked format [(RECFM=F). Since the data 
set is loaded in chronological sequence, the order in which the user 
presents each segment to be stored in the data set establishes the 
hierarchic arrangement of segments in the data base. A sequence field 
is not required in the root segment type of an HSAM data base. 
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TP-BSAN 
BATCH- 
QSAM 
OR BSAM 
BLOCK #1 BLOCK #2 BLOCK #3 


Figure 4-11. One Data Base Record of HSAM Data Base on Tape 


When a sequence field is defined in the root segment type, each data 
base record must be presented for loading in ascending key sequence. 
Within each data base record, all segments must be presented for loading 
in hierarchic sequence. 


In the data set, one or more consecutive blocks are used to store a 
data base record. Each block is filled with segments of a data base 
record until the remaining space is not sufficient for the next segment 
to be stored. When not sufficient for the next segment to be stored, 
the remaining space in the block is padded with zeros and the segment is 
stored in the next consecutive block. When the last segment of a data 
base record has been stored in a block, any unused space, if sufficient, 
is filled with segments from the next data base record. 


Initial entry to an HSAM data base is through get unique or get next 
calls. When the first call is issued, the search for the desired 
segment starts at the beginning of the data base in storage, and passes 
sequentially through all segments stored in the data base until the 
desired segment is reached. After the desired segment is reached, the 
position it occupies is used as the starting position for any additional 
calls that process the data base in a forward direction. From current 
position in an HSAM data base that has a unique sequence field defined 
in the root segment type, if a get unique is issued to retrieve a 
segment that is forward in the data base, the search starts from current 
position and moves forward to the desired segment. If the desired 
segment requires backward movement in the data base, the processing 
option parameters G or GS, which are specified during PSBGEN, determine 
how backward movement is accomplished. The G processing option 
specifies the get function only, whereas the GS processing option 
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specifies get segments in ascending sequence only. If GS has been 
specified and backward movement in a data base is reguired to satisfy a 
get unique, the search for the desired segment will start at the 
beginning of the data base and move forward. Under the same conditions 
when the G processing option is specified, from current position the 
search will move backwards in the data base. This is accomplished by 
backspacing over the block just read on tape or disk, and the block 
previous to the block just read, then reading the previous block forward 
until the desired segment is found. 


An HSAM data base can be randomly processed through get unique calls 
within one volume. When no sequence field has been defined in the root 
segment type of an HSAM data base, each get unique causes the search for 
the desired segment to start at the beginning of the data hbase 
regardless of current position. 


Insert, delete and replace calls cannot be used when processing an 
existing HSAM data base. The only calls that are valid for processing 
an existing HSAM data base are the get calls which enable retrieval of 
segments from the data base only. To update an HSAM data base, it must 
be reloaded. 


Simple HSAM 


A simple HSAM data base is an HSAM data base that contains only one 
segment type. When a simple HSAM data base is defined, occurrences of 
the segment type are loaded into the data base without prefixes. 


HISAM STORAGE ORGANIZATION 


In a HISAM data base, segments within each data base record are 
related through physical adjacency in storage as with an HSAM data base. 
Unlike HSAM however, in a HISAM data base each data base record is 
indexed. In defining a HISAM data base, the user must define a unique 
sequence field in the root segment type of the data base. When defined, 
the seguence field values in occurrences of the root are used to index 
to each data base record in the data base. 


In defining a HISAM data base, the user can specify VSAM or the 
combination of ISAM/OSAM as the access methods to be used for the data 
base. When ISAM/OSAM are specified, he can also specify that the HISAM 
data base be stored as one to 10 data set groups. If VSAM is specified, 
a HISAM data base can have only one data set group. When VSAM is 
specified as the access method, a data set group contains one key 
sequenced data set and one entry sequenced data set. When ISAM/OSAM are 
specified as the access methods each data set gtoup contains one ISAM 
data set and one OSAM data set. In both cases, one data set, key 
sequenced or ISAM, is used for primary storage of segments and as an 
index. The other data set, entry sequenced or OSAM, is used for 
overflow storage of segments. The terms used to describe data set 
groups are primary and secondary. A primary data set group contains the 
root segment type. Ali other data set groups are called secondary data 
set groups. 


HISAM Data Base Stored as One Data Set Group 


When only one data set group is defined for a HISAM data base, the 
data base is stored as shown in Figure 4-12. Each key sequenced or ISAM 
logical record will contain in hierarchic sequence an occurrence of the 
root, plus all dependents of the root that there is sufficient space for 
in the logical record. When no space remains for the remaining segments 
in a data base record, the remaining segments are stored in hierarchic 


Data Base Design Considerations 4,2! 


sequence in one or more logical records of the entry sequenced or OSAM 
data set. To relate all logical records in both data sets that contain 
segments in one data base record, a direct address pointer is stored in 
each logical record to chain them in hierarchic sequence. 






DATA BASE RECORD STRUCTURE 


KEY SEQUENCED ENTRY SEQUENCED 


OR 


OR 
ISAM DATA SET OSAM DATA SET 


EXPRI 


Figure 4-12. HISAM Data Base Record in Storage (Single Data Set Group) 


The structures of logical records for VSAM, and ISAM or OSAM data 
sets are shown in Figure 4-13. The first 3 bytes of each logical record 
for ISAM or OSAM, and the first 4 bytes of each logical record for VSAM 
are used for a direct address pointer. The pointer is used to maintain 
root segments in ascending key sequence and to maintain all segments 
within a data base record in hierarchic sequence when new segments are 
inserted into a data base after initial load. Following the pointer are 
one or more segments of a data base record in hierarchic sequence. At 
the end of the last segment in the logical record for VSAM, ISAM or 
OSAM, a one byte segment code of zero is stored to indicate that the 
last segment in the logical record has been reached. Following the zero 
segment code for VSAM, remaining space ina logical record is residual. 
Following the zero segment code for ISAM or OSAM, there are three bytes 
of zeros, or a 3 byte direct address pointer. 
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ISAM/OSAM Format 


A SEGMENT SEGMENT SEGMENT 


VSAM Format 


ft SEGMENT SEGMENT SEGMENT 


NOTES: 










SEGMENT 
CODE 
O 


(1 BYTE) 






000 
OR RESIDUAL 
NOTE 2 
RESIDUAL 









SEGMENT 

CODE 
O 

(1 BYTE) 











1. The pointer is comprised of the 3 byte relative record number 
of the OSAM data set logical record that contains a root inserted 
after initial load. 


2. The pointer is comprised of the 3 byte relative record number 
of the OSAM data set logical record that contains the next 
dependents in hierarchic sequence. 


3. The pointer is comprised of the 4 byte relative byte address of 
the entry sequenced data set logical record that contains the 
next dependents in hierarchic sequence. 


Figure 4-13, HISAM Data Base VSAM, ISAM and OSAM Logical Record 
Formats 


Three bytes of zeros indicate that this logical record contains the 
last segment in a data base record. If not zeros, a three byte pointer 
points to the logical record that contains the next segments in the data 
base record in hierarchic sequence. 


In a VSAM data set, one or more logical records are contained in each 
control interval. In an ISAM or OSAM data set, one or more logical 
records are contained in each block. A control interval or block is the 
unit of data transferred between an I/O device and main storage. For 
VSAM and ISAM data sets, the respective access method uses an index to 
address a specific control interval or block in a data set. For an 
entry sequenced data set or an OSAM data set, direct addresses are used 
to address each control interval or block respectively in a data set. 


To load a HISAM data base, occurrences of the root segment type nust 
be arranged in ascending key sequence, and all dependents of each root 
must follow that root in hierarchic sequence. In the key sequenced or 
ISAM data set, consecutive logical records within a control interval or 
block are used to store root segment occurrences in ascending key 
sequence. The first logical record contains the root segment with the 
lowest key, the next consecutive logical record contains the root 
segment with the next higher key, and the last logical record contains 
the root segment with the highest key in that control interval or block. 
In addition, control intervals or blocks within a data set are loaded in 
ascending root segment key sequence, this enables a given data base 
record to be accessed directly through the key of its root. 
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HISAM Logical Record Lengths 
Logical record lengths are a major consideration in a HISAM data | 
base. They affect space and access time. } 


Extremely short or long logical records tend to increase wasted 
space. Since only complete segments are stored in a logical record, a 
gap of space is usually unused at the end of each logical record. The 
number of gaps increases as the LRECL becomes small, and the size of 
gaps increases as the logical record length becomes large (if data hbase 
records are shorter than the logical record length, the remaining space 
is lost). 


All segments in a logical record are accessed with one read of an I/0 
device. Accessing additional logical records may require additional 
reads and seeks depending on physical positioning. The number of seeks 
and reads to access an entire data base record is in proportion to the 
number of logical records which comprise that data base record, and 
therefore increases as the logical record length decreases. 


To choose a value for LRECL, several choices should be tried with the 
following restrictions: 


1. Primary data set group: 


The minimum length for a logical record in the primary data set 
must be at least equal to the maximum root segment Length, 
including prefix, plus 5 bytes for VSAM or 7 bytes for ISAM. The 
minimum length for a logical record in the overflow data set must 
be at least equal to the longest segment in the data set group, 
including prefix, plus 5 bytes for VSAM or 7 bytes for OSAM. If 
a HISAM data base using ISAM/OSAM has only one physical segment 
type, the ISAM/OSAM overhead is 3 bytes, not 7 bytes. 


4) 
2. Secondary data set group: J 


The minimum length for a logical record in the primary data set 
must be at least equal to the longest second level segment type, 
including prefix, plus the root key length plus 7 bytes. The 
ninimum length for a logical record in the overflow data set must 
be at least equal to the longest segment in the data set group, 
including prefix, plus 7 bytes. 


3. The logical record length in the overflow data set must be 
greater than or equal to the logical record length in the primary 
data set. 

4, For ISAM/OSAM the naximum length cannot exceed the physical block 
size of the I/O device used. Note that ISAM requires keyed 
blocks while OSAM uses non-keyed blocks. For VSAM, the maxinunm 
logical record length is 30720. 


5. For ISAM/OSAM, LRECLs must be divisible into physical block size 
(1/2, 1/3, 1/4, etc.) 


6. VSAM LRECL values must be an even length. 


For each LRECL value chosen, the average usable space within a record 
can be calculated as follows: 


u = (LRECL - A - B) 
2 
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where: 
u = usable data characters per logical record. 


A = weighted average of segment lengths not including the 
root segment. 


B = 7 for ISAM/OSAM, and 5 for VSAM. 


The number of logical records required for a particular type data 
base record is then calculated by dividing the usable logical record 
length into the total length of the data base record. By breaking the 
file into a number of typical record types and calculating the space 
required for each, the total space requirements can be approximated. 


As stated before, the number of reads required to obtain an entire 
data base record is proportional to the number of logical records it 
requires. By using "typical" records the number of logical records 
required for the entire file can be calculated. Due to record blocking 
and the IMS/VS buffer pool management, the actual number of accesses 
required will be less than the number of logical records. A file 
reguiring fewer (large logical record length) logical records can be 
accessed faster than the same file with an LRECL value requiring more 
logical records [small logical record length). 


If the number of logical records (relative access time) and total 


space are plotted against several trial LRECL values, the graph should 
take the following general form: 


High 


) 
No. of Log Records (----) 


TOTAL SPACE ( 





LRECL increase —> 


As shown, as the value of LRECL gets larger, the number of logical 
records decreases continually, until the LRECL specification equals the 
largest data base record length. At this point, the number of logical 
records equals the number of data base records. 


The total space requirements tend to rise 1f the value of LRECL is 
either too long or too short. Once several trial LRECL values have been 
plotted, it should be possible to pick a good one for the file. 
Consideration should be given to the relative importance of space and 
access time in the individual situation. 


The ISAM and OSAM portions of the data base need not have the same 


LRECLs. To determine the effect of different values for LRECL, each 
portion of the data base must be figured separately as above. 
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TO maintain root segment in ascending key sequence when new roots are 
inserted after initial load of a HISAM data base, one method is used 
when VSAM is specified as the access method for the data base and 
another method is used when the combination of ISAM and OSAM are 
specified as the access methods. 


The method shown in Figure 4-14 is used when VSAM is specified. The 
proper control interval in the key sequenced data set for the new root 
is obtained, and if the control interval has a free logical record, the 
hew root is stored in ascending key sequence in the control interval by 
pushing all logical records that contain roots with higher keys to the 
right one position. If no free logical record exists in the control 
interval, the control interval is split forming two control intervals 
that are both equal in size to the original. 


Insert root with key of 15 


oud 10 BYTES OF 
|peP | DEP | per| DEP| FREE LRECL FREE LRECL FREE LRECL | VSAM CONTROL 
INFORMATION** 


10 BYTES OF 
VSAM CONTROL 


BEFORE 






INFORMATION ** 





CONTROL INTERVAL 


* The pointer is comprised of the 4 byte relative byte address of the 
entry sequenced data set logical record that contains the next 
dependents in hierarchic sequence. 


** For unblocked data sets, the VSAM control information is 
only 7 bytes. 


Figure 4-14. Root Segment Insertion into Key Sequenced Data Set 
Control Interval 


Each new control interval will contain approximately one half of the 
logical records that were stored in the original control interval which 
results in free logical records in the last half of each new control 
interval. After the control interval has been split, the new root is 
stored in the proper control interval in ascending key sequence by 
pushing all logical records that contain roots with higher keys to the 
right one logical record. 


To maintain root segments in ascending key sequence when ISAM and 
OSAM are specified as the access methods for a HISAM data hbase, the 
method shown in Figure 4-15 is used. Each new root is stored in an OSAM 
logical record. To maintain root key sequence, a direct address pointer 
is placed at the beginning of the ISAM logical record that contains the 
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root segment with the next higher key to point to the OSAM logical 
record that contains the inserted root as shown in Example 1. Example 2 
shows a second root segment being inserted in the OSAM data set. The 
logical record that contains the root with the next higher key in the 
ISAM data set points to the OSAM logical record that contains the root 
with the lowest key. That OSAM logical record in turn points to the 
OSAM logical record that contains the next higher key. 


1 = _INSERT_ROOT IS EXAMPLE 3 - INSERT ROOT 15 





LOGICAL RECORD 29 






Figure 4-15. Root Segment Insertion When ISAM/OSAM are HISAM Data Base 
Access Methods 


In a HISAM data base, the order of chaining a series of root segments 
can significantly impact updates. If the addition of root segments is a 
part of the update, insertions should be made in descending sequence, 
highest key first when ISAM/OSAM are the OS access methods. This 
reduces the number of reads necessary to find a point at which to insert 
a new root. It can be seen in Figure 4-16 that, even with a short 
Chain, the insertion of higher root keys requires a larger number of 
accesses than the insertion of lower keys. For example, to insert Root 
46 it was necessary to read both Roots 34 and 36. The insertion of 32, 
however, only required the reading of Root 34. Note that the building 
of long chains of roots occurs only when a large number of updates 
affects the same area of the data base. The need for descending 
insertions is less if the inserts are distributed over the data base. 
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When VSAM is used for a HISAM data base, new roots can be inserted in 
either ascending or descending sequence. Ascending sequence should 
provide slightly faster performance. 


———____—___—_———— PHYSICAL RECORD- 


OGICAL RECORD — LOGICAL RECORD iP Sih RECORD 


| ROOT DEP1 " DEP1 i DEP 
A!) ; PE 


}¢———LOG!CAL RECORD 1——4—LOGICAL RECORD 2——>} 
mare BLOCK A 


ROOT i ROOT 
RD 47 32 4tH 


—— LOGICAL RECORD 1 
PHYSICAL BLOCK B 


Figure 4-16. HISAM Root Segment Insertion Sequence 


HISAM Dependent Segment Insertion 


The method used to maintain the hierarchic sequence of segments 
within a data base record when new dependent segments are inserted into 
a HISAM data base is essentially the same for both VSAM, and the 
combination of ISAM and OSAM access methods. 


In a HISAM data base, one logical record in the primary storage data 
set and, if necessary, one or more logical records in the overflow 
storage data set, are used to store each data base record. Within each 
logical record and across all logical records that contain segments in 
one data base record, segments are hierarchically related through their 
physical sequence in storage. Within each logical record, segments are 
physically stored in hierarchic sequence, and across logical records, a 
direct address pointer relates each logical record to the next in 
hierarchic sequence. 
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Figure 4-17 shows how the physical sequence of segments within a data 
base record in storage is maintained when inserting dependents into a 
data base after initial load. Example 1 shows a dependent segment being 
inserted into a logical record that contains sufficient space for the 
new dependent. The new dependent is stored in its proper hierarchic 
position within the logical record by shifting the segments that will 
hierarchically follow it to the right within the logical record. 

Example 2 shows segments displaced to a logical record at the end of the 
overflow data set when the inserted segment did not leave sufficient 
space for them at the end of the original logical record. In Example 3, 
the length of the segment being inserted is greater than the space 
remaining in the original logical record even after displacing following 
segments in that logical record, so all are placed in an overflow 
storage logical record. Example 4 shows an inserted segment that will 
not fit into the original logical record, and a displaced segment that 
will not fit into the first overflow logical record with the inserted 
segment. Two overflow logical records are used, and they are chained 
together in hierarchic sequence. 


In the previous examples, the overflow logical records referred to 
are at the end of the entry sequenced data set when VSAM is the access 
method specified, and they are at the end of the OSAM data set when 
ISAM/OSAM are specified as the access methods. In both cases, logical 
records at the end of the respective data sets are used for newly 
inserted or displaced segments from both the primary storage data set 
and the overflow storage data set. 
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Example 1- Space available in logical record for dependent being inserted. 


Key sequenced, 
ISAM or OSAM 
data set 


BEFORE 


ROOT 


INSERT DEP20 
AFTER 


ROOT 
SEGM100 





Example 2- Space available in logical record for dependent being inserted by displacing 
existing segments in logical record to an OSAM or entry sequenced 
data set logical record. 






Key sequenced, or 
ISAM data set 










BEFORE 


ROOT 


INSERT DEP15 





AFTER 


ROOT 
SEGM100 






Entry sequenced 
or 
OSAM data set 





*The pointer is at the beginning of VSAM logical records. 


Figure 4-17 [Part 1 of 3). Dependent Segment Insertion into a HISAM Data 
Base with One Data Set Group 
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Example 3 Space available in logical record after segments are displaced but 
dependent being inserted is too large. 


a Key sequenced, 


ISAM or OSAM 
data set 
BEFORE 
ROOT 
SEGM100 
AFTER 


ROOT 
SEGM100 





Insert DEP27 (DEP27 greater in 
length than DEP30) 


Entry sequenced or 
OSAM data set 


Ne 


*The pointer is at the beginning of VSAM logical records 


Figure 4-17 (Part 2 of 3). Dependent Segment Insertion into a HISAM Data 
Base with One Data Set Group 
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Example 4- Space available in logical record after segments are desplaced to 
overflow, however, segment being inserted is too large and segment 
displaced will not fit in 1st overflow. 


Key sequenced, or 
ISAM data set 


BEFORE 


ROOT 
SEGM100 


R 
AFTER INSERT DEP15 


ROOT 
SEGM100 





Entry sequenced or 
OSAM data set 


AFTER| [D a 


AFTER 


*The pointer is at the beginning of VSAM logical records 


Figure 4-17 (Part 3 of 3). Dependent Segment Insertion into a HISAM Data 
Base with One Data Set Group 


ISAM/OSAM: When segments are deleted in a HISAM data base that uses 
ISAM/OSAM, segments are Simply marked as being deleted in the delete 
byte contained in their prefix. They are not physically deleted from a 
data base. To regain space occupied by deleted segments, a HISAM data 
base must be unloaded and reorganized by the user through the HISAM 


reorganization unload and reload utilities. 


VSAM: Segment deletion in a HISAM data base using VSAM is the same as 
stated for ISAM/OSAM except as follows. When a root segment is deleted 
from a HISAM data base that uses VSAM, the logical record in the key 
sequenced data set that contains the root is either erased or the delete 
byte is marked as when using ISAM/OSAM. An erase is only done when 
processing the data base in batch mode, the root or any dependent of the 
root is not involved in an active logical relationship, and there is 
only one PCB per data base within the PSB. 
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Secondary Data Set Groups 

Secondary data set groups should be considered for HISAM data bases 
using ISAM/OSAM as the OS/VS access methods in two cases. They should 
be considered when storage space is wasted because an efficient logical 
record length cannot be found for the primary data set group due to 
segment types in the data base whose lengths vary considerably. And, 
when access to a dependent segment type in the data base is too time 
consuming through the primary data set group. 


As in a primary data set group, each secondary data set group uses 
two data sets. An ISAM data set is used as the first storage data set 
and as the index to the first segment type defined in that data set 
group. An OSAM data set is used as the overflow storage data set. The 
benefit gained in defining multiple data set groups is that each data 
set group defined can have different logical record and block lengths. 
In addition, the occurrences of the first segment type defined in each 
secondary data set group are indexed through the key of the root segment 
they follow in a data base record. When defining a secondary data set 
group, the minimum LRECL must be expanded by the amount necessary to 
append sequence field keys of the root segment type onto occurrences of 
the first segment type defined in the secondary data set group. 


When only one data set group is defined for a HISAM data base, the 
segments in each data base record are stored in hierarchic sequence 
using one logical record in the first storage data set and, if 
necessary, one or more logical records in the overflow data set. To 
index each data base record, the key of the root that starts each data 
base record is used. When multiple data set groups are defined, one 
logical record in the first storage data set of each data set group and, 
if necessary, one or more logical records in each overflow data set are 
used to store the segments of one data base record as shown in Figure 
4-18. To index each data base record, the key of the root that starts 
each data base record is duplicated and is used to index the segments in 
each secondary data set group that are in the same data bas? record. In 
the figure, the secondary data set group contains a duplicate of the key 
of the root that starts that data base record. The duplicate key is 
followed by the first occurrence of the description segment type in the 
data base record, which in turn, is followed by all other segments in 
that base record in hierarchic sequence. 


The use of multiple data set groups to store a HISAM data base has an 
affect on main storage requirements. Each data set group requires 
additional space in the DMB pool. 


Simple HISAM 


A simple HISAM data base is a HISAM data base that contains only one 
segment type. When defining a simple HISAM data base, VSAM must be the 
access method specified. When defined, occurrences of the segment type 
are loaded into the data base without prefixes, thus making the data 
sets that contain the data base compatible for use by VSAM as well as 
IMS/VS. 
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Figure 4-18. One Data Base Record in a HISAM Data Base (Multiple Data 
Set Group) 





HDAM AND HIDAM STORAGE ORGANIZATIONS 


Two of the primary advantages gained with HDAM and HIDAM data bases 
are space reuse and the ability to access segments within the data base 
through direct address pointers. Either data base type is stored in one 
or more VSAM entry sequenced or OSAM data sets depending on the number 
of data set groups defined. Space within each data set is managed 
through free space elements and bit maps. When segments are inserted or 
deleted from either data base type, the space used or freed by those 
segments is recorded in a bit map to enable its reuse when inserting new 
segments. To hierarchically relate segments in HDAM and HIDAM data 
bases, direct address pointers are used. In either data base type, 
hierarchic, physical child/physical twin or any combination of the two 
types of pointers can be specified. 


The storage organization methods used for HDAM and HIDAM data bases 
are essentially the same. The primary difference between HDAM and HIDAM 
data bases is that access to cccurences of the root segment type is 
through a user randomizing module for an HDAM data base, and through an 
index for a HIDAM data base. To access a given root in an HDAM data 
base, the randomizing module examines the key of the root, and through 
hashing or some other arithmetic technique, computes the address of the 
root and passes it to IMS/VS. To access the same root in a HIDAM data 
base, an index must be searched by IMS/VS to find the address of the 
root. When found, the root is accessed. By using a randomizing nodule 
to locate roots, the I/O operations required to search the index are 
eliminated. 
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HDAM 


To use an HDAM data base, the user must supply a randomizing module. 
The randomizing module determines where each root should be stored in 
the data base, and supplies the address of each root stored to IMS/VS 
each time that root must be accessed. Addresses supplied by a 
randomizing module consists of a relative block number and an anchor 
point number. Anchor points are stored in the anchor point area of each 
control interval or block, and each is a four byte direct address 
pointer to a root. To access a given root, the relative block number 
locates a specific control interval or block in relation to the start of 
the data set, and the anchor point number locates a specific anchor 
point in the anchor point area of that control interval or block. 


Figure 4-19 shows the organization of an HDAM data base in storage. 
The entry sequenced or OSAM data set in the primary data set group is 
divided into two areas called the root addressable area and the overflow 
area. The root addressable area is the first n control intervals or 
blocks in the data set, and the overflow area is the remaining portion 
of the data set. 


The root addressable area is the area in which the user randomizing 
module assigns roots. The length of the root addressable area is 
specified by the user through the DBDGEN utility. Also specified is the 
number of anchor points to be placed in the anchor point area of each 
control interval or block in the root addressable area. A third 
parameter specified is the maximum number of bytes of a data base record 
to be stored in the root addressable area. The root addressable area is 
used as the primary storage area for segments in each data base record, 
and the overflow area is used for overflow storage. Since data base 
records vary in length, the bytes parameter is used to control the 
amount of space used for each data base record in the root addressable 
area. The bytes parameter limits the number of segments of a data base 
record that can be consecutively inserted into the root addressable 
area. When consecutively inserting a root and its dependents, each 
segment is stored in the root addressable area until the next segment to 
be stored will cause the total space used to exceed the bytes parameter. 
The total space used for a segment is the combined lengths of the prefix 
and data portions of the segment. When exceeded, that segment and all 
remaining segments in the data base record are stored in the overflow 
area. It should be noted that the bytes parameter only controls 
segments consecutively inserted in one data base record. Consecutive 
inserts are inserts to one data base record that are not intervened by 
any call to process a segment in a different data base record. 


The general criteria to determine the size of the root addressable 
area is: 


Number of bytes of 

a data base record the expected number 
to be stored in the x of data base records 
root addressable area 


aS ek ae ae eS ee ee ee et ees, = required size 
(Number of bytes per block) of the root 
addressable 
area in blocks 
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Figure 4-19. HDAM Data Base Record in Auxillary Storage 


In addition, if distributed free space is specified, the space 
estimate obtained must be multiplied by one factor for free blocks and 
another for free space within each block as shown in the following 
formula: 


(Total Space) = (Minimum Space) X _fbff xX 1 
fbfFt-1 l-f£spft 
100 
where: 
2s f£bff < 100 or Fb£EF = 0 and O S$ fspf < 100 


See "Distributed Free Space" in this chapter for definitions of £bfft 
and fspf. 
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At least root segments should be stored in the root addressable area. 
In addition, active dependent segments should be placed in the root 
addressable area since this will provide fast access to them because of 
their physical proximity to the root segment. When all space in the 
root addressable area is occupied, all segments inserted {roots 
included) are placed in the overflow area. 


The size of the root segment addressable area is fixed with DBD 
generation. The overflow area however, can be dynamically extended if 
the overflow storage data set allocation is specified as secondary 
allocation. 


To load each data base record into an HDAM data base, the user 
randomizing module generates a relative block and anchor point number 
for the root that starts that data base record and passes then to 
IMS/VS. IMS/VS in turn, attempts to store the root in the control 
interval or block specified. If space is available in that control 
interval or block, the root is stored and a four byte direct address 
pointer to the root is stored in the specified anchor point position in 
the anchor point area of that control interval or block. When space is 
not available in the control interval or block specified, IMS/VS uses 
the HD space search algorithm to find the available space nearest to the 
control interval or block specified by the randomizing module. When 
found, the root is stored and a pointer to that root is stored in the 
Original anchor point position and relative block number specified by 
the randomizing module. 


When a randomizing module produces the same relative block and anchor 
point number for multiple roots, the specified anchor point points to 
one, and the rest are chained through physical twin pointers. When a 
unique sequence field has been defined in the root segment type, the 
anchor point points to the root with the lowest key and the rest are 
chained in ascending key sequence through physical twin pointers. When 
a unigue sequence field is not defined, the insert rules of FIRST, LAST 
or HERE determine the sequence in which the roots are chained. All 
roots chained from a given anchor point are called synonyms since all 
have the same relative block and anchor point number. To reduce the 
length of root segment synonym chains if they affect performance, the 
user should increase the number of root anchor points specified for each 
control interval or block in the root addressable area. The user 
randomizing routine can then distribute the roots across more anchor 
points, thereby reducing the number of synonyms per anchor point. 


After a root is loaded into the root addressable area, the next 
segments in a data base record are stored following the root until the 
bytes parameter causes the remaining segments ina data base record, if 
any, to be stored in the overflow area. 


HIDAM 


A HIDAM data base in auxiliary storage is actually comprised of two 
data bases that are normally referred to collectively as a HIDAM data 
base. When defining each through the DBDGEN utility, one is defined as 
the primary HIDAM index data base and the other is defined as the HIDAM 
data base. In the following discussion the terms "HIDAM data base’ will 
refer to the HIDAM data base defined through DBDGEN. 


The primary HIDAM index data base is used to index to the data base 
records stored in a HIDAM data base. When a HIDAM data base is defined 
through DBDGEN, a unique sequence field must be defined in the root 
segment type. The resulting key in the sequence field of each 


Data Base Design Considerations 4,37 





occurrence of the root is used by IMS/VS to create an index segment for 
each root that is stored in the index data base. To identify which root 
an index segment indexes, the key in the sequence field of a root is 
stored in the data portion of an index segment. To index to that root, 
the address of the root in the HIDAM data base is stored as a direct 
address pointer in the prefix of its index segment. 


When the user loads a HIDAM data base, the primary HIDAM index data 
base is loaded automatically by IMS/VS. In loading a HIDAM data base, 
all roots must be inserted in ascending key sequence, and all dependents 
of a root must be inserted following that root in hierarchic sequence. 
As each root is stored in the HIDAM data base, IMS/VS generates the 
index segment for that root and stores it in the index data base. 


The index data base consists of an ISAM and an OSAM data set when 
ISAM/OSAM are specified as the access methods for the data base, or it 
consists of a key sequenced data set when VSAM is specified as the 
access method as shown in Figure 4-20. When ISAM/OSAM are specified for 
the index data base, the ISAM data set is used for storage of index 
segments created during initial load of a HIDAM data base, and it is 
called the primary data set. The OSAM data set is used for storage of 
index segments created when new roots are added to a HIDAM data base 
after initial load, and it is called the overflow data set. When VSAM 
is specified for the index data base, the key sequenced data set is used 
for both index segments created during initial load and after initial 
load. 


When ISAM/OSAM are used for an index data base, all index segments 
for roots initially loaded are stored in ascending key sequence in the 
ISAM data set. When roots are added after initial load, the index 
segment for that root is stored in the first available logical record in 
the OSAM data set. When this occurs, a pointer is stored at the 
beginning of the logical record in the ISAM data set that contains the 
next higher key. The pointer points to the logical record in the OSAM 
data set that contains the added index segment. When multiple index 
segments have to be chained from the same logical record in the ISAM 
data set, the logical record in the ISAM data set points to the OSAM 
logical record that contains the index segment with the lowest key. Any 
additional OSAM logical records to be chained are chained from the first 
OSAM logical record in ascending key sequence. Since index segments 
added after initial load are stored in the OSAM data set, their access 
requires additional I/O operations. To improve performance degraded by 
root inserts, the index data base should be reorganized through the 
HISAM Reorganization Unload and Reload utilities. 


A HIDAM data base is stored in from one to ten entry sequenced or 
OSAM data sets depending on the number of data set groups defined and 
the access method specified. Each data set group uses one entry 
sequenced data set when VSAM is specified as the access method, and one 
OSAM data set when OSAM is the access method specified. When initially 
loading segments into a HIDAM data base or when inserting segments into 
a HIDAM data base after initial load, the HD space search algorithn is 
used to find the most suitable space available. 
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HIDAM Data Base Root Segment Type Pointer Options 
If forward only hierarchic or physical twin pointers are specified 
for the root segment type of a HIDAM data base, sequential access to ) 
each root segment is accomplished by using the index. When forward and 
backward hierarchic or physical twin pointers are specified for the root 
segment type, for sequential processing the index is only used to access 
the first root segment. From the first root, additional roots can be 
processed sequentially without further reference to the index. 


Format of Data Sets Used for HDAM and HIDAM 


In defining an HDAM or HIDAM data base, the user can specify VSAM or 
OSAM as the access method to be used for the data base, and he can also 
specify that the data base be stored as one to ten data set groups. 
When VSAM is specified, each data set group consists of one entry 
sequenced data set. When OSAM is specified, each data set group 
consists of one OSAM data set. In either case, the resulting data set 
will have an unblocked format. When not specified by the user, DBDGEN 
generates logical record lengths for the data sets that are equivalent 
to a guarter-track, third-track, half-track, or full-track block. 


Direct address pointers within the prefix of a segment and the anchor 
point(s) of a block are constructed by the following formula: 


Pointer Value = (Block Size) X (Block Number) + (Offset within Block). 


This formula is also used for pointers in the prefix of segments of 
an INDEX data base when relating to segments in a HIDAM data base. 


In order that all segments will be on half word alignment, within the 
data set a slack byte is added to the end of any segment in HDAM data | 
bases or HIDAM whose total length is an odd number. } 
The control fields used in managing entry sequenced or OSAM data sets 
for HDAM and HIDAM data bases are (See Figure 4-21): 
e Free space anchor point 
e Free space element 


e Anchor point area 


e Bit map control interval or blocks 
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Free Space Anchor Point 


Fach control interval or block in an entry sequenced or OSAM data set 
respectively starts with a four byte free space anchor point [FSEAP) 
field. The field contains, in the first two bytes, the offset in bytes 
to the first free space element in that control interval or block. The 
second two bytes contain a flag that identifies bit map blocks. For 
blocks other than bit map blocks, the second two bytes of the field 
contain zeros. 


Fre 


space Element 


A free space element identifies each area of free space in a control 
interval or block that is eight bytes or more in length. To identify 
each area of free space, a free space element occupies the first 8 bytes 
of each area of free space. The fields in each free space element are: 


e Free space chain pointer field (CP) -- This field contains, in 
bytes, the offset to the next free space element in the control 
interval or block from the beginning of the control interval or 
block. The length of this field is 2 bytes. 


e Available length field (AL) -- This field contains in bytes the 
length of the vacant space that this free space element identifies. 
The value in the available length field includes the length of the 
free space element itself. The length of this field is 2 bytes. 


e Task ID field (ID) -- This field contains the task ID of the progran 
that freed the space that is identified by this free space element. 
The task ID enables a given program to free and reuse the same space 
during a given scheduling without contending for that space with 
other programs. 


The task ID consists of a one-byte calendar date followed by a three 
byte cumulative sync point count for the day. 


Anchor Point Area 


For an HDAM data base, the user specifies the number of four byte 
direct address root anchor points desired in each control interval or 
block in the root addressable area. For each anchor point specified, 
four bytes of space is reserved in the anchor point area of each control 
interval or block in the root addressable area. The space for anchor 
points is not reserved in those control intervals outside the root 
addressable area, including the bit map control intervals. This space 
is initially made free space and is available just as other free space 
in a control interval. 


For a HIDAM data base, when forward-only hierarchical or physical 
twin pointers are specified for the root segment type, one 4U-byte anchor 
point is present in each control interval or block. The anchor point 
addresses the last root inserted into the control interval and the roots 
are chained in the reverse order from the sequence in which they were 
inserted into the control interval. With a forward-only (not forward 
and backward) pointer at the root level, it is impossible for IMS/VS to 
keep the roots chained in key sequence when new roots are inserted into 
an existing data base. Because the forward pointer chains roots in 
reverse time sequence and not in key sequence, it is not used by IMS/VS 
to obtain the next sequential root. The index is used to do sequential 
processing. For a HIDAM data base we recommend that you use no-twin, 
twin forward and backward, or hierarchical forward and backward pointers 
at the root level. When one of these options is used, no anchor point 
is placed in the control interval. If your processing is primarily 
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random, no-twin is best because all accesses to the root segments are 
via the index. If your processing is primarily sequential, use physical 
or hierarchical forward and backward. With these pointers the roots are 
Chained in key sequence. 


A bit map control interval or block starts with a two byte free space 
chain pointer field. The field always contains zeros in a bit map 
control interval or block in the root addressable area of an HDAM data 
base since no space is available in those bit map control intervals or 
blocks for segments. The next two bytes contain a bit map flag. A low 
order one in the second two bytes of a control interval or block 
indicates that the control interval or block contains a bit map. The 
same two bytes in all other control intervals or blocks in a data set 
will contain zeros. The next 0 to n bytes of a bit map control interval 
or block are for root anchor points. Following the anchor point area 
when present, the remainder of the control interval or block is a bit 
map. 


The first control interval or block of the first extent of the data 
set specified for each data set group in an HDAM or HIDAM data hbase is 
used for a bit map. If, however, the organization is VSAM, the second 
control interval is used for the bit map and the first control interval 
is reserved. In the bit map, each bit is used to describe whether or 
not space is available in a particular control interval or block. The 
first bit corresponds to the control interval or block the bit map 
itself is in, and each consecutive bit corresponds to the next 
consecutive control interval or block in the data set. When the bit 
value is one, it indicates that the associated control interval or block 
has sufficient space remaining to store an occurrence of the longest 
segment type defined in this data set group. When the bit value is 
zero, sufficient space is not available for an occurrence of the longest 
segment type defined in this data set group. The first bit map ina 
data set contains n bits that describe space availability in the next n 
consecutive control intervals or blocks in the data set. After the 
first bit map, another bit map is stored at every nth control interval 
or block to describe space availability in the remaining control 
intervals or blocks in the data set. 


inserts and Deletes in HDAM and HIDAM Da 


The technigues used to insert or delete segments are the same for 
both HDAM and HIDAM data bases. The technigues involve use of bit maps, 
space available chains and available length fields. The three are used 
to find space when inserting a segment, or to record free space when a 
segment is deleted. 


The following HD space search algorithm is used to find the most 
Suitable space for a segment being inserted into an HDAM or HIDAM data 
base. 
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HD Space Search Algorithm 


SEARCH CRITERIA: When searching for space, if space the exact size of 
the request is found, it is used; otherwise, three free areas are ) 
selected in the following order of preference: 


1. Smallest 2 REQUEST + min. segment in data set 
2. Smallest & REQUEST *2 
3. Smallest 2 REQUEST 


From this set, the first area that does not alter bit map setting is 
selected, if there is one. Otherwise, the first area found is selected. 


1. SAME BLOCK 

2. ANY BLOCK CURRENTLY IN BUFFER POOL ON SAME TRACK 

3. ANY BLOCK CURRENTLY IN BUFFER POOL ON SAME CYLINDER 

4. ANY BLOCK ON SAME TRACK WHERE SPACE FOR MAXIMOM SEGMENT LENGTH 
EXISTS (Based on bit map) : 

5. ANY BLOCK ON SAME CYLINDER WHERE SPACE FOR MAXIMUM SEGMENT LENGTH 
EXISTS (Based on bit map) 

6. ANY BLOCK CURRENTLY IN BUFFER POOL WITHIN + N CYLINDERS 

7. ANY BLOCK ON + N CYLINDERS WHERE SPACE FOR MAXIMUM SEGMENT LENGTH 
EXISTS (Based on bit map) 

8. ANY BLOCK IN BUFFER POOL AT END OF DATA SET 

9. ANY BLOCK AT END OF DATA SET (Based on bit map) 

10. ANY BLOCK IN THE DATASET WHERE SPACE FOR MAXIMUM SEGMENT LENGTH 
EXISTS (Based on bit map) 


In the algorithm, the same block as that which contains the 
immediately preceding segment in the hierarchy of a data base record is 
chosen for the new segment insertion under search criteria one. If not 
satisfied, search criteria two through ten are used in sequence in 
attempting to obtain space for insertion. 


Deletes 


Deletion of a segment from an HDAM or HIDAM data base involves: 


e Updating the pointers in any other segments that point to the 
deleted segment. 


e Accumulating the space occupied by the deleted segment on the space 
available chain for the block and possible adjustment to the bit 
map. If a deleted segment is adjacent to an already available area 
of space, the two areas are combined into one. 


Figure 4-22 illustrates the deletion of segment EXPR4 and the 
incorporation of the space it occupied on the space available chain. 
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Distributed Free Space 
A consideration affecting HDAM or HIDAM data base performance is a 
result of certain types of dependent segment insert activity. After an ) 


HDAM or HIDAM data base is initially loaded or reorganized, high segment 
insert activity may degrade performance. This degradation occurs when 
added segments are not placed physically adjacent to their related 
segments. For HDAM or HIDAM, segments inserted after a data base is 
initially loaded or reorganized are stored at the end of their data set 
group, or in the position of previously loaded segments that have been 
deleted from that data set group as follows: 


Space for an inserted segment in an HDAM or HIDAM data base is 
acquired by scanning a user specified number of disk cylinders to locate 
the free space nearest to its related segments. If no space is found, 
the segment is inserted at the end of that data set group. This method 
attempts to place added segments in the position physically closest to 
their related segments to keep direct access storage device access time 
to a minimum. However, since this method does not always place added 
segments in space physically adjacent to their related segments, data 
bases must be reorganized periodically to eliminate the degradation to 
performance. 


The distributed free space option can be selected during DBDGEN for 
HDAM and HIDAM data bases. It is intended to minimize degradation to 
performance caused by insert activity, and in so doing, decrease the 
frequency in which HDAM or HIDAM data bases must be reorganized. It 
accomplishes this by allowing the user to specify, on the DATASET 
statement for each data set group, periodic blocks of free space and/or 
a percentage of free space in each block to be left vacant during 
initial load or reorganization of the data base. These free spaces are 
then used after data base initial load or reorganization to store added 
segments physically close to their reiated segments. J 


The FRSPC= operand on the DATASET statement is used to specify free 
Space in each data set group of an HDAM or HIDAM or data base. In the 
operand, any combination of two parameters can be specified. One is the 
fbff (free block frequency factor). The fbf£ specifies that every nth 
block in a data set group will be left as free space during data base 
load or reorganization {where fbff=n). The range of fbff includes all 
integer values from 0 to 100 excluding fbff=1. The second parameter 
that can be specified is the fspf (free space percentage factor). The 
fspf specifies the minimum percentage of each block in a data set group 
that is to be left as free space during load or reorganization. The 
range of fspf is from 0 to 99. 


HISAM AND HIDAM KEY SEGMENTS 


For HISAM or HIDAM index data bases using ISAM/OSAM, IMS/VS generates 
an additional root segment and stores it as the last root segment in the 
data base. This additional root segment has the sequence field filled 
with X'FF's. It is generated and placed in the data base by IMS/VS 
because add2d root segments are chained from the root with the next 
higher sequence field key. 


HIDAM data bases using VSAM also contain an X'FF' key segment. It is 
used for twin backward pointing at the root level. 


For variable length or compressed segments, an X'FF' key segment is 
aliocated the maximum length specified for the segment type, and the 
size field of the segment has the high order bit turned on (X '8XXX'). 
This segment is never compressed. ) 
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OPTIONS AVAILABLE IN DEFINING PHYSICAL DATA BASES 


Following is a summary of the characteristics of the four physical 
data base types. 
ASAM 


e All segments and data base records are related through physical 
adjacency. 


e Stored as a sequential data set. 


e Can only retrieve segments from existing data base. To update 
regvires reload. 


e Can be stored on tape. 


HISAM 


e Segments within data base records are related through physical 
adjacency. 


e Indexed access to data base records. 
e User can specify multiple data set groups. (ISAM/OSAM only) 


e Space occupied by deleted segments is not reusable, except when root 
segments are deleted in a key sequenced data set. 


e VSAM or the combination of ISAM/OSAM can be specified as the 
Operating system access method. 


e Logical relationships using symbolic pointers. 


e Secondary Indexing using symbolic pointers for single data set 
groups. 


e When VSAM is specified as the operating system access method for a 
HISAM data base, the additional options available are: 


- Variable Length Segments 


- User Segment Compaction/Expansion Routines 


HDAM OR HIDAM 


e Segments within data base records are related through hierarchic 
and/or physical child/physical twin direct address pointers. 


e Access to the root in each data base record is through a user 
randomizing module for HDAM and through an index for HIDAM. 


e User can specify multiple data set groups. 
e Space occupied by deleted segments is reusable. 


e VSAM or OSAM (combination of ISAM/OSAM for HIDAM index) can be 
specified as the operating system access method. 


e Logical relationships using direct address or symbolic pointers. 


e Distributed Free Space. 
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e Secondary Indexing using direct address or symbolic pointers 


e When VSAM is specified as the operating system access method for the 
data base, the additional options available are: 


- Variable Length Segments 
- User Segment Compaction/Expansion Routines 


For information on defining the Main Storage Data Base (MSDB) and the 
Data Entry Data Base [DEDB) see the “Fast Path Data Bases" section in 
the chapter "Design Considerations for the Fast Path Feature." 


LOGICAL RELATIONSHIPS 

In multi-application data management systems, data duplication is 
often a problem. Duplicates in storage waste storage space and cause 
duplicate maintenance. Duplicates are caused when a given type of data 
is common to several applications, but each application requires the 
common data stored in relation to different types of data, or in 
combination with different types of data. To eliminate storage 
duplication, logical relationships are used. Logical relationships 
enable the user to store a given segment type once and to define that 
segment type as dependent on one segment type in a physical data base 
and a different segment type in a logical data base. Logical 
relationships are also used to create logical data bases that contain a 
combination of segment types from different physical data bases without 
duplicating them. This means the segment types in two different 
physical data bases, for two different applications, can be combined 
into a logical data base for a third application without creating a 
third physical data base. 


All logical relationships establish a relationship between two 
segment types in one or more physical data bases. They are defined in 
the physical data bases of the segment types they relate to, and they 
are used when the related segment types are processed through a logical 
data base. When defined between segment types in the same physical data 
base, a logical relationship enables a different hierarchy of segment 
types to be defined for the segment types in that physical data base. 
When defined between segment types in different physical data bases, it 
enables a hierarchy of segment types to be defined that combines the 
segment types in both data bases into a single data base. In each case, 
the new hierarchy of segment types is defined through the NBDGEW utility 
to create a logical data base. The hierarchy of segment types for a 
logical data base is comprised of a subset of the physical and logical 
relationships defined between the segment types in their physical data 
bases. 


Logical relationships enable occurrences of two seqment types to he 
stored independently of each other, yet enable an application program to 
process them through a logical data base as if stored in relation to 
each other. Through the logical data base, the relationship between the 
two segment types appears to be that of a physical parent segment type 
and one of its physical child segment types in a physical data base. An 
application processes occurrences of the related segment types through 
their logical data base in the same manner as occurrences of a physical 
parent segment type and a physical child segment type are processed in a 
physical data base. 
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A logical relationship is defined in the physical data base or data 
bases of the segment types being related. Through a logical 
relationship, segment types in the same or different physical data bases 
are related in a manner that is in most cases transparent to application 
programs using the physical data bases. To enable use of a logical 
relationship defined between two segment types in one or more physical 
data bases, a logical data base must be defined. 


The terms used to describe the segment types involved in logical 
relationships are physical parent, logical parent, and logical child. 
The terms physical parent and logical parent are used to describe the 
two segment types being related through a logical relationship. The 
term logical child is used to describe one or both of the additional 
segment types that are required to relate two segment types through a 
logical relationship. 


METHODS OF RELATING SEGMENT TYPES THROUGH A LOGICAL CHILD 


Three types of logical relationships can be defined in IMS/VS data 
bases. The three types are unidirectional, physically paired 
bidirectional, and virtually paired bidirectional logical relationships. 
For each of the three types of logical relationships, a logical child 
segment type relates two segment types by one of two methods. The first 
method described in the following text is used for unidirectional and 
physically paired bidirectional logical relationships. The second 
method described is used for virtually paired bidirectional logical 
relationships. In both methods, a logical child is physically related 
to one of the segment types being related through a logical 
relationship. In addition for the first method, the logical child 
points to the other segment type. In the second method the Logical 
child points to the other segment type, and is pointed to by the other 
segment type. Figure 4-23 shows the first method of relating segment 
types through a logical child segment type. 
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Figure 4-23. Relating Occurrences of SKILL to Occurrences of NAME 


Method One 


Figure 4-23 shows occurrences of the SKILL segment type being related 
to occurrences of the NAME segment type through occurrences of an 
additional segment type that is reguired to relate NAME and SKILL 
segments. A logical child is an additional segment type that is 
required to relate two segment types through a logical relationship. A 
logical child segment type relates two segment types by being physically 
related to one segment type and by pointing to the other segment type. 
The segment type that the logical child segment type is physically 
related to is called the physical parent of the logical child. The 
segment type that the logical child segment type points to is called the 
logical parent of the logical child. The pointer ina logical child 
that points to a logical parent is called a logical parent pointer. In 
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Figure 4-23, NAME is the physical parent, SKILL is the logical parent, 
and NAMESKILL is the logical child segment type. To establish the 
physical relationship between the NAME and NAMESKILL segment types shown 
in Figure 4-23, NAMESKILL is defined as a physical child segment type of 
NAME in the physical data base of the NAME segment type. Since NAME and 
NAMESKILL are a physical parent and a physical child segment type in the 
same physical data base, occurrences of each are related when loaded 
into their physical data base. To relate an occurrence of SKILL to an 
occurrence of NAME in storage, the user loads an occurrence of 
NAMESKILL, the logical child segment type, as a physical child of a 
given NAME segment. This process is repeated for each occurrence of the 
logical parent that is to be related to that NAME segment. When loading 
a logical child segment into its physical data base, the user identifies 
which logical parent segment the logical child points to, by placing the 
concatenated key of the logical parent in the data portion of the 
logical child segment. Since the concatenated key of a logical parent 
segment is the symbolic pointer to that segment in its physical data 
base, when the user loads logical child segments as physical children of 
a given physical parent segment, the respective logical parent segment 
pointed to by each logical child is related to the physical parent 
segment. When processing the related segment types through a logical 
data base, it is the physical relationship between occurrences of the 
physical parent and logical child segment types in their common physical 
data base, plus the logical parent pointer contained in each logical 
child segment, that enables access to related occurrences of the logical 
parent segment type from each occurrence of the physical parent segment 
type. 


Method Iwo 


In the second method of relating two segment types throagh a logical 
child segment type, all of the conditions described for the first method 
remain the same. The logical child segment type is physically related 
to its physical parent segment type and points to its logical parent 
segment type. One occurrence of the logical child segment type is 
loaded as a physical child of a given physical patent segment for each 
occurrence of the logical parent segment type that is to be related to 
that physical parent. To identify which logical parent segment is being 
related to a physical parent segment through a logical child segment, 
the user piaces the concatenated key of the logical parent in the data 
portion of each logical child segment loaded. Through the relationship 
of physical parent and logical child segments in their physical data 
base, and the logical parent pointer in each logical child segment, 
related occurrences of the logical parent segment type can be accessed 
from physical parent segments. In addition, logical child pointers are 
used in the logical parent segment type, and logical twin and physical 
parent pointers are used in the logical child segment type, as shown in 
Figure 4-24. The additional pointers are used to enable accessing 
specific occurrences of the physical parent segment type that are 
related to each occurrence of the logical parent. Logical twins are 
multiple occurrences of the same logical child segment type that point 
to the same occurrence of the logical parent segment type. When 
specified in the logical child segment type, logical twin pointers point 
from each logical twin to the next to chain together all logical twins 
that point to a given logical parent. The physical parent pointer in 
each occurrence of the logical child segment type is generated 
automatically by IMS/VS to enable access to the physical parent segment 
of each logical child from that logical child. A logical child pointer 
is specified for the logical parent segment type to enable accessing a 
logical child segment from a logical parent segment. A logical child 
pointer points from a given logical parent segment to one of the logical 
twins, which also points back to that logical parent segment. Since all 
logical twins that point to the same logical parent are chained through 
logical twin pointers, and each logical child contains a physical parent 
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pointer, the specific physical parent segments that are related to a 


given logical parent segment can be accessed from that logical parent 
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Figure 4-24. Relating Occurrences of NAME to Occurrences of SKILL 
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Logical Relationship Paths 

The physical relationship between physical parent and logical child 
segments in their physical data base, and the logicai parent pointer in 
each logical child segment creates a physical parent to logical parent 
path between each physical parent segment and the logical parent 
segments related to each physical parent segment. To define use of the 
path in a logical data base, the logical child and logical parent 
segment types are defined as one concatenated segment type that is a 
physical child of the physical parent segment type as shown in Figure 
4-25. 
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Figure 4-25. Defining a Physical Parent to Logical Parent Path ina 
Logical Data Base 


In addition, when logical child pointers are used in the logical 
parent segment type, and logical twin and physical parent pointers are 
used in the logical child segment type, a logical parent to physical 
parent path is created between each logical parent segment and the 
physical parent segments related to each logical parent segment. To 
define use of the path in a logical data base, the logical child and 
physical parent segment types are defined as one concatenated segment 
type that 1s a physical child of the logical parent segment type as 
shown in Figure 4-26. 
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Figure 4-26. Defining a Logical Parent to Physical Parent Path in a 
Logical Data Base 


When use of a physical parent to logical parent path between segment 
types is defined in a logical data base, the physical parent segment 
type invoived in the logical relationship is the physical parent of the 
concatenated segment type. When an application program retrieves an 
occurrence of the concatenated segment type from a physical parent 
segment, an occurrence of the logical child and the respective logical 
parent pointed to by the logical child are concatenated and presented to 
the application program as one segment. When use of a logical parent to 
physical parent path is defined in a logical data base, the logical 
parent segment type is the physical parent of the concatenated segment 
type. When an application program retrieves an occurrence of the 
concatenated segment type from a logical parent segment, an occurrence 
of the logical child and the physical parent segment pointed to by the 
logical child are concatenated and presented to the application progran 
as one segment. 


In each case the physical parent or logical parent segment type 
included in the concatenated segment type is called the destination 
parent. For a physical parent to logical parent path, the logical 
parent is the destination parent in the concatenated segment type. For 
a logical parent to physical parent path, the physical parent is the 
destination parent in the concatenated segment. 


Logicai Child Segment 


By definition, a logical child segment contains the concatenated key 
of the destination parent followed by intersection data, if any. A 
logical child segment relates a specific physical parent segment to a 
specific logical parent segment. Since a logical child is the point of 
intersection for a physical parent and logical parent segment, any data 
contained in a logical child segment in addition to the concatenated key 
of a destination parent is called intersection data. When defining a 
logical child segment type in its physical data base, the length 
specified for the segment type must be sufficient to contain the 
concatenated kev of a logical parent. Any length greater than that 
required for the concatenated key can be used for intersection data. 
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To identify which logical parent segment will be pointed to by a 
logical child segment, the concatenated key of the logical parent 
segment must be present, with each logical child segment, in the user's 
I/O area when the logical child segment is initially presented for 
loading into a data base. However, if the logical parent segment is in 
a HDAM or HIDAM data base, its concatenated key may not be written to 
storage when the dogical child segment is loaded. If the logical parent 
is in a HISAM data base, a logical child in storage must contain the 
concatenated key of its logical parent. 


When a concatenated segment is retrieved through a logical data hbase, 
it contains the concatenated key of the destination parent, followed by 
intersection data in the logical child segment, which in turn is 
followed by the data in the destination parent segment. Figure 4-27 
shows the format of a retrieved concatenated segment in the user I/0 
area. The concatenated key of the destination parent is returned with 
each concatenated segment to identify the destination parent retrieved. 
IMS/VS obtains the concatenated key of the destination parent from the 
logical child in the concatenated segment, or by constructing the 
concatenated key. If the destination parent is the logical parent of 
the logical child and the concatenated key of the logical parent has not 
been stored with the logical child, IMS/VS constructs the concatenated 
key of the logical parent segment and presents it to the user as a part 
of the concatenated segment. If the destination parent is the physical 
parent of the logical child, IMS/VS must always construct the 
concatenated key of the physical parent. 


| Logical child segment | Destination parent segment | 


snearaaee ear er Intersection Destination 


Figure 4-27. Format of Concatenated Segment Returned to User I/0 Area 










UNIDIRECTIONAL LOGICAL RELATIONSHIP 


A unidirectional logical relationship is used to relate two segment 
types in one direction. Figure 4-28 shows the schematic view of a 
unidirectional logical relationship that is defined between two segment 
types in the same or different physical data bases, and the resulting 
view of the segment types involved that is defined in a logical data 
base. In a physical data base, a logical child segment type is defined 
as a physical child of one segment type, and a direct address or 
symbolic pointer is specified in the logical child segment type to point 
to the other segment type. This results in creating a physical parent 
to logical parent path between occurrences of the two segment types when 
they are loaded into storage. 
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Figure 4-28. Unidirectional Logical Relationship 


PHYSICALLY PAIRED BIDIRECTIONAL LOGICAL RELATIONSHIP 


A physically paired bidirectional logical relationship is used to 
relate two segment types in two directions, and to provide the same 
intersection data in both directions. Figure 4-29 shows the schematic 
view of a physically paired bidirectional logical relationship that is 
defined in a physical data base or data bases, and the resulting views 
of the segment types involved that are defined in a logical data base. 
In a physical data base or data bases, a logical child segment type is 
defined as a physical child of each of the two segment types being 
related, and a direct address or symbolic logical parent pointer is 
specified for each logical child segment type. One logical child 
segment type creates a physical parent to logical parent path between 
occurrences of the two segment types in storage in one direction, and 
the other logical child segment type creates a physical parent to 
logical parent path between occurrences of the two segment types in 
storage in the other direction as shown in Figure 4-29, When defining 
each logical child segment type in its physical data base, the user 
specifies that each logical child segment type is paired with the other 
logical child segment type to enable IMS/VS to maintain the same 
intersection data in paired logical child segments: In storage, paired 
logical child segments provide two different paths between the same two 
segments, and both logical child segments contain the same intersection 
data. For example, in Figure 4-30 under the NAME segment ADAMS, the 
occurrence of NAMESKILL that points to ARTIST, and under the SKILL 
segment ARTIST, the occurrence of SKILLNAME that points to ADAMS are 
physically paired logical child sagments since they provide two 
different paths between the same two segments and they contain the same 
intersection data. In a physically paired logical relationship, if the 
user updates intersection data in one logical child segment, IMS/VS 
automatically updates the intersection data in the paired logical child 
segment. When initially loading paired logical child seqments, the user 
must place the same intersection data in each of the paired logical 
child segments. 


During the initial load of a data base that contains physically 
paired logical children, the application program must load (using an 
ISRT call) both sides of the physical pair. The intersection data for 
the paired segments must be identical. After the initial load, in any 
update step, if an insert, delete, or replace is done for one of the 
paired segments, IMS/VS performs the same function for the paired 
segment. 
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Figure 4-29. Physically Paired Bidirectional Logical Relationship 
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Figure 4-30. Physically Paired Logical Child Segments 


VIRTUALLY PAIRED BIDIRECTIONAL LOGICAL RELATIONSHIP 


In a virtually paired bidirectional logical relationship, one logical 
child segment type in storage relates two segment types in two 
directions, and provides the same intersection data in both directions. 
Figure 4-31 shows the schematic view of a virtually paired bidirectional 
logical relationship that is defined in a physical data base or bases, 
and the resulting views of the segment types involved that are defined 
in a logical data base. 


Data Base Design Considerations 4.57 


Physical Data Base(s) Logical Data Base (s) 





Concatenated Segment Types 


Real logical child Virtual logical child 
(Represents B when 
accessed from C) 


Key: 
PP- Physical parent pointer 
LP—Logical parent pointer 
LCF -Logical child first pointer 


Figure 4-31. Virtually Paired Bidirectional Logical Relationship 


To define a virtually paired bidirectional logical relationship, two 
logical child segment types are defined in the physical data bases 
involved in the logical relationship, but only one is actually placed in 
storage. The logical child segment type that is defined and results in 
storage is called the real logical child. The logical child segment 
type that is defined, but does not result in storage is called the 
virtual logical child. 


In a virtually paired bidirectional logical relationship, occurrences 
of the real logical child create physical parent to logical parent, and 
logical parent to physical parent paths between occurrences of the two 
segment types being related. To accomplish this the real logical child 
is defined as a physical child segment type of one of the segment types 
being related, and a symbolic or direct address logical parent pointer 
is specified for the real logical child sagment type. This creates a 
physical parent to logical parent path between occurrences of the two 
segment types being related. In addition, logical child pointers are 
specified for the logical parent segment type of the real logical child, 
and logical twin pointers are specified for the real logical child 
segment type to create a logical parent to physical parent path in 
storage between occurrences of the two segment types being related. The 
physical parent pointers required in occurrences of the real logical 
child for a logical parent to physical parent path are generated 
automatically by IMS/VS. 


For the physical parent to logical parent path, the user controls the 
seguence in which occurrences of the real logical child are accessed 
from their physical parent segment by defining a sequence field in the 
real logical child segment type, or by specifying use of the insert rule 
of first, last or here when defining the real logical child in its 
physical data base. For the logical parent to physical parent path, the 
user controls the sequence in which occurrences of the real logical 
child are accessed from their logical parent by defining a virtual 
logical child segment type as a physical child of the logical parent of 
the real logical child, and in addition, by defining a sequence field in 
the virtual logical child. Or, the user can specify a second insert 
rule of first, last or here that controls the sequence of real logical 
child segments as viewed from their logical parent segment. The insert 
rule that controls the sequence of real logical child segments as viewed 
from their physical parent segment is specified on the SEGM statement 
that defines the real logical child segment type in its physical data 
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base. The insert rule that controls the sequence of real logical child 
segments as viewed from their logical parent is specified on an LCHILD 
statement. As input to DBDGEN when defining a segment type in a 
physical data base that is used as a logical parent in one or more 
logical relationships, an LCHILD statement must follow a SEGM statement 
that defines a logical parent segment type for each logical child 
segment type of that logical parent. LCHILD statements identify the 
logical child segment types of a logical parent by following a SEGM 
statement that defines a logical parent. For a virtually paired 
bidirectional logical relationship, when no sequence field or a 
non-unique sequence field is defined for the real logical child segment 
type as viewed from its logical parent segment type, the insert rule of 
first, last or here specified on an LCHILD statement controls the 
sequence in which occurrences of the real logical child are accessed 
from their logical parent segment. 


To enable using a sequence field for sequencing occurrences of the 
real logical child from its logical parent segment type, a virtual 
logical child segment type is defined. A virtual logical child segment 
type is defined as a physical child of the logical parent seqment type 
of the real logical child. A virtual logical child segment type is 
defined in the physical data base of the logical parent of the real 
logical child to represent the view of the real logical child when 
accessing the real logical child from its logical parent. In defining a 
virtual logical child segment type, a name is specified for the virtual 
segment type and the name of the real logical child segment type is 
associated to the name specified. To enable sequencing occurrences of 
the real logical child through sequence field values from the logical 
parent, a sequence field is defined in the virtual segment type. Since 
the virtual segment type represents the real logical child as viewed 
from its logical parent, the sequence field defined represents fields in 
the real logical child segment type as viewed from its logical parent 
type. 


Since a logical child segment, by definition in a logical data base 
contains the concatenated key of a destination parent, followed by 
intersection data, if any, the concatenated key of the destination 
parent is included as a part of the logical child segment type when 
defining fields within the logical child segment. For a physical parent 
to logical parent path, fields can be defined within the logical child 
segment type that are comprised of the concatenated key of the Logical 
parent. For a logical parent to physical parent path, fields can be 
defined within the logical child segment type that are comprised of the 
concatenated key of the physical parent. In addition for a logical 
parent to physical parent path, fields defined within the logical child 
segment type can be comprised of non-contiguous data in the logical 
child. 


POINTERS AND THE COUNTER USED IN LOGICAL RELATIONSHIPS 


Logical relationships can be defined in HISAM, HDAM and HIDAM data 
bases, or between any combination of the three. In defining logical 
relationships in each type or between types, the data organization 
methods used for the data bases must be considered when specifying the 
pointers used in logical relationships. Physical adjacency in storage 
is used to relate segments in a HISAM data base which means that all 
pointers to segments stored in a HISAM data base must be symbolic. In 
HDAM and HIDAM data bases, segments in storage are related through 
direct address pointers. Segments stored in HDAM and HIDAM data bases 
can be pointed to by symbolic or direct address pointers. 
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The following pointers are used in defining logical relationships 
(see Figure 4-32): 
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Figure 4-32. Pointers Used in Logical Relationships 


Logical Parent Pointer 
A logical parent pointer points from a logical child segment to a 
logical parent segment. To point to a logical parent segment type in a 

HISAM data base, a symbolic pointer must be stored with each logical 
child segment. To point to a logical parent segment type in an HDAM or 
HIDAM data base, a symbolic pointer can be stored with each logical 


child segment and/or a direct address logical parent pointer can be 
specified. 
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Logical Child/Logical Iwin Pointers 

Logical child and logical twin pointers are only specified in 
virtually paired bidirectional logical relationships. The logical child 
pointers that can be specified are logical child first, or logical child 
first and last pointers. A logical child first, or a combination of 
logical child first and last pointers are stored in the prefix of a 
logical parent segment to point to each of its logical child segment 
types. A logical child first pointer points to the first occurrence of 
a logical child segment type, and a logical child last pointer points to 
the last occurrence of that segment type when viewed from the logical 
parent. 


The logical twin pointers that can be specified are logical twin 
forward or the combination of logical twin forward and backward 
pointers. Logical twins are multiple logical child segments of the same 
type that point to the same occurrence of a logical parent. A logical 
twin forward pointer points from a given logical twin to the logical 
twin stored after it and a logical twin backward .pointer points from a 
given logical twin to the logical twin stored before it. Use of the 
logical twin backward pointer improves delete performance. 


In HDAM and HIDAM data bases involved in logical relationships, 
physical parent pointers are generated automatically by IMS/VS. IMS/VS 
places physical parent pointers in the prefix of all logical child and 
logical parent segments, and in the prefix of all segments on which a 
logical child -or logical parent segment is dependent in its physical 
data base. This creates a path from a logical child or logical parent 
segment to the root segment on which the logical child or logical parent 
segment is dependent. Since all segments on which a logical child or 
logical parent segment is dependent are chaired through physical parent 
pointers from the logicai child or logical parent segment to its root, 
access to those segments in reverse order is enabled through a logical 
data base. 


Counter 


A four-byte counter is required in all logical parent segments that 
do not contain logical child pointers. It is stored in the prefix of a 
logical parent segment to maintain a count of how many logical child 
segments point to the logical parent. When required, it is placed in 
logical parent segments automatically by IMS/VS. 


DEFINING SEQUENCE FIELDS FOR DATA BASES INVOLVED IN LOGICAL 
RELATIONSHIPS 


To avoid potential problems in processing data bases involved in 
logical relationships, unique sequence fields should be defined in all 
logical parent segment types, and in all segment types that a logical 
parent is dependent on in its physical data base. When unigue sequence 
fields are not defined in all segment types on the path to and including 
a logical parent segment type, multiple logical parent segments in a 
data base can have the same concatenated key. When multiple logical 
parent segments have the same concatenated key, problems can arise 
during initial data base load, and after initial data base load when 
symbolic logical parent pointers in logical child segments, are used to 
establish position on a logical parent segment to be processed. 
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At initial data base load time, if logical parent segments with 
nonunigue concatenated keys exist in a data base, the logical 
relationship resolution utilities attach all logical child segments that 
contain the same concatenated key to the first logical parent segment in 
a data base that has that concatenated key. 


When inserting or deleting a concatenated segment and position for 
the logical parent portion of the concatenated segment is determined by 
the logical parents concatenated key, positioning for the Logical parent 
stops on the first segment at each level of the logical parents data 
base that satisfies the key equal condition for that level. For insert 
when using this method of establishing position in the logical parents 
data base, if a segment is missing on the path to the logical parent 
segment to be inserted, a GE status code is returned to the application 
program. Under the same conditions for deletion of a logical parent 
segment a 0803 abnormal termination occurs. 


RULES FOR DEFINING LOGICAL RELATIONSHIPS IN PHYSICAL DATA BASES 


Following are the rules that must he followed when defining logical 
relationships in physical data bases. 


1. A logical child segment type must have a physical parent segment 
type and a logical parent segment type. 


2. A logical child segment type can have only one physical parent 
segment type and one logical parent segment type. 


3. A logical child segment type is defined as a physical child 
segment type in the physical data base of its physical parent. 


4%. A logical child segment type is always a dependent segment type 
in a physical data base, and as such, it can be defined at any 
level except the first level of a data base. 


5. In its physical data base, a logical child segment type can not 
have a physical child segment type defined at the next lower 
level in the data base that is also a logical chiid. 


6. A logical child segment type can have physical child segment 
types. However, if a logical child segment type is physically 
paired with another logical child segment type, only one of the 
paired segment types can have physical child segment types. 


Logical Parent 


1. A logical parent segment type can be defined at any level of a 
physical data base including the root level. 


2. A logical parent segment type can have one or multiple logical 
child segment types. Each logical child segment type related +o 
the same logical parent segment type defines a logical 
relationship. 


3. A segment type in a physical data base can not be defined as both 
a logical parent and a logical child. 


4%. A logical parent segment type can be defined in the same physical 


base as its logical child segment types, or in a different 
physical data base. 
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Physical Parent 


1. A physical parent segment type of a logical child cannot also be 
a logical child. 


REPLACE, INSERT AND DELETE RULES 


XXXXXXXXXXXX KXXXXXXXXXXXX 
x CUSTOMER x x LOANS x 
x PP x x LP x 
KXXXXXXXXXXXX m XXXXXXXXXXXX 
x * * Vv 
x * * Vv 
xXXXXXXXXXXXXXXXKXXXXXXXX * * Vv 
x x * * Vv 
x x * &* Vv 
XXX XXXXXXXXX xXXXXXXXXXxX * VVVVVVVVVVVY 
x ACCOUNTS x xX BORROW x v CUST Vv 
x x x LC x Vv VLC v 
XXXXXXXXXXXX XXXXXXXXXXXX VVVVVVVVVVVV 
x 
x 
KRXXXXXXXXXXX 
xX PAYMENTS x 
x x 
XX XXXXXXXXXX 
PHYSICAL PATH PHYSICAL PATH 
TO CUSTOMER and BORROW TO LCANS 
XXX XXXXXXXXX XXXKKXXXXXXX 
x CUSTOMER x x LOANS x 
x x x x 
XXXXXXXXXXXX XXXXXXXXXKXX 
x x 
x x 
XXXXXXXXKXNWXXXXX XXXXXKXKXXXXXXXXXXX 
X BORROW/LOANS x x CUST/CUSTOMER x 
x x x x 
XXXXXXXXXXXXXXXX XXXXXXXXXKXXXXKKX 
LOGICAL PATH LOGICAL PATH 
TO LOANS TO CUSTOMER and BORROW 


Insert, Delete, and Replace rules are needed when a segment is 
involved in a logical relationship because that segment is updatable 


from two paths; a physical path and a logical path. 


Think a minute about the following questions: 


1. Should the CUSTOMER segment be insertable by both its physical 


and logical paths? 


2. Should the BORROW segment be replaceable via only the physical 
path, or by both the physical and logical paths? 


3. If the LOANS segment is deleted by its physical path, should it 
be erased from the data base or should it be marked as physically 
deleted but remain accessible by its logical path? 
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4, If the logical child segment BORROW or the concatenated segment 
BORROW/LOANS is deleted from the physical path, should the 
logical path CUST/CUSTOMER also be automatically deleted or 
should the logical path remain? 


The answer to these questions depends on the application, but the 
enforcement of the answer depends on choosing the correct 
insert/delete/replace rules for the logical child, logical parent and 
physical parent segments. 


The application processing requirements must be determined first, and 
the rules that support (enforce) those application processing 
requirements must be determined second. 


For instance, the answer to question one depends on whether or not 
the application defines that a CUSTOMER segment must have been 
previously inserted into the Data Base prior to accepting the loan. An 
insert rule of physical (P) on the CUSTOMER segment would prohibit the 
insertion of the CUSTOMER segment except by the physical path. While an 
insert rule of virtual (V) would allow inserting the CUSTOMER segment by 
either the physical or logical path. 


It probably makes sense for a customer to be checked {past credit, 
time on current job, etc) and the CUSTOMER segment inserted prior to 
approving the loan and inserting the BORROW segment. Thus, the insert 
rule of the CUSTOMER segment should be physical (P) to prevent this 
segment from being inserted logically (which incidentally provides 
better control of the application). 


Consider question three. We can reason two ways: (1) If it is 
possible for this load institution to terminate a type of loan (cancel 
7% car loans -- create 9% car loans) before everyone who has that type 
of loan has fully paid the loan, then we are saying that it's possible 
for the LOANS segment to be physically deleted and still be accessible 
from the logical path. This condition is supportable by specifying the 
delete rule for LOANS as either logical {L) or virtual [V) but not as 
physical (P). 


The physical [P) delete rule prohibits physically deleting a logical 
parent segment prior to all its logical children having been physically 
deleted (which means the logical path to the logical parent is deleted 
first). 


INTRODUCTION SUMMARY 


Data Base Administrators should examine all application needs and 
decide who may insert, delete, and replace segments involved in logical 
relationships and how those updates are to be made [physical path only 
or physical and logical path). The insert/delete/replace rules in the 
physical DBD and the PROCOPT parameter in the PCB are the means of 
control. These rules are explained in detail in the following pages. 
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PPP FIRST 
SEGM NAME= , » » ¢ « « ekULES=(LLL,LAST ) 
VVV HERE 
B 
insert. ____/// 


delete_____// 
replace____/ 


P = PHYSICAL 

L = LOGICAL 

V = VIRTUAL 

B = BIDIRECTIONAL VIRTUAL 


The operands of the RULES parameter are positional. Position one 
defines the INSERT rule, position two defines the DELETE rule and 
position three the REPLACE rule. 


For example, RULES=PLV says the insert rule is physical, the delete 
rule is logical and the replace rule is virtual. Notice the "B" rule is 
only applicable for delete. 


The second positional operand (FIRST,LAST,HERE) does not apply in any 
way to a discussion concerning LOGICAL UPDATE RULES and was only 
included to maintain the correctness of the coding example. 


In general the "P" rule (physical) is the most restrictive and the 
"Vv" rule {virtual) the least restrictive with the "L" rule (logical) 
somewhere in between. 


ROLES are applicable only to the segments involved in logical paths; 
the Logical Child segment and its Logical Parent and Physical Parent 
segments. Rules are not coded for the virtual logical child. 


XXXXXXXXXXKXX XXXXXXXXXXXX 
x CUSTOMER x x LOANS x 
x PP x x LP x 
xX XXXXXXXKXXX * XXXXXXXXXKXX 
x * * Vv 
x * * Vv 
XXXXXXXXXXXXXXXXXXXXXXXXEX * * Vv 
x x * * Vv 
x x *x* % Vv 
XXX XXXXXXXXX XXXXXXXXKXXXX * VVVVVVVVVVVV 
x ACCOUNTS x x BORROW x Vv CUST Vv 
x x x LC x Vv VLC v 
XXXXXXXXXXXX XXXXXXXXXXXX VVVVVVVVVVVY 
x 
x 
XXXXXXXXXXXX 
xX PAYMENTS x 
x x 
XXXXXXXXXXXX 
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THE REPLACE RULES 


Applicable to the Physical Parent, Logical Parent and Logical Child 
segnents of a Logical Path. 


1. PHYSICAL: The segment can only be replaced when retrieved via a 
physical path. If this rule is violated, no data is replaced and 
an '"RX* status code is returned. 


2. LOGICAL: The segment can only be replaced when retrieved via a 
physical path. If this rule is violated, no data is replaced, 
however, an 'RX’ status code is not returned. A '}PW' status code 


is returned. 


3. WIRTUAL: The segment can be replaced when retrieved by either a 
physical or logical path. 


The Replace Calli 
A replace can be performed only on that portion of a concatenated 
segment to which an application program is data sensitive. 


If no data is changed in a segment, no data is replaced and no 
replace rule is violated. 


If data in a concatenated segment has been changed, data is replaced 
only if neither portion of the concatenated segment violates its replace 
rule. 


The replace rule is not checked for a segment which is part of a 
concatenated segment but was not retrieved. 


The status code returned to an application program will indicate the 
first violation that was detected. These status codes are: 


‘AM! = Replace attempted and PROCOPT#R 
'DA' - Key field of segment was changed 
"RX! = Replace rule violated 
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Physical Replace Rule Example 


RULES= (--P) 


XXXXXXXXXXXX 
x CUSTOMER x 
x PP x 
XXXXXXXXXXXX 
x 
x 
XX MXXXXXXXEXXXXXXXXXXXXX 
x 
x 
XXX XXXXXXXXX XX XXX 
x ACCOUNTS x x BO 
x x x 
XXXXXXXXXXXX XXXXX 
XXXXX 
x PAY 
x 
XXXXxX 
XXX XXXXXKXXX 
x CUSTOMER x 
x x 
KXXXXXXXXXXX 
x 
x 
XXXXXNXXXXXXXXXXKX 
xX BORROW/LOANS x 
x x 
XXXXXXXXXXXEXXXX 
GHU ‘CUSTOMER! 
REPL 
GHN *BORROW/LOANS! 
REPL 


The physical replace rule prevents replacing the LOANS segment as 


part of a concatenated segment. Replacement must be ‘by the segment's 


physical path. 


RULES= (~-P) 


XXXXXXXXXXXX 
x LOANS x 
x LP x 
™ XXXXXXXXXXXX 
* Vv 
rd * _v 
x * * Vv 
x * * Vv 
x * * v 
XXXXxxx * VVVVVVVVVVVY 
RROW x V CUST v 
LC x V VLC Vv 
XXXXXXX VVVVVVVVVVVV 
Xx RULES= (--P) 
x 
XXXXXXX 
MENTS x 
x 
XXXXXXX 
XXXXXXKKKXXX 
x LOANS x 
xX x 
XXXKXXKXXXXXX 
x 
x 
XXXXXXXXXKXKKXXKXX 
x CUST/CUSTOMER x 
x x 
XXXXXXXXXXXXXXXXX 


STATUS CODE=' Bp' 


.STATUS CODE='"PB! 


STATUS CODE=' BB 


STATUS CODE="RX'* 
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XXXXXXXXXXXX XXXXXXKXXXXXX ) 
ROULES=(--L) x CUSTOMER x RULES= [(--L)x LOANS x 
x LP x x LP x 
xXXXXXXXKXXXXX * XXXXXXXXXXXX 
x * * x 
x * x 
XXXXXXXXXXKXXXXXXXXXXXXXX * * x 
x x * * x 
x x * x 
XXXXXXXXXXXX XXXXXXXXxXxxx * * XXXXXXXXXXKXX 
x ACCOUNTS x x BORROW x x Xx cust x 
x x x LC x x LC x 
XXXX XXXXXXXX XXXXXXXXXXXX XXXXXXXXXXXX 
x ROULES=any ROLES=any 
x 
KXXXXXXXXxXXX 
X PAYMENTS x 
x x 
XXXXXXXXXXXX 
XXXXXXXXXXXX XXXXXXXXXXXX 
x CUSTOMER x x LOANS x 
x x x x 
XXXXXXXXXXXX XXXXXXXXXXXX 
x xX 
x x 
XXXXXXXXXXXKXXXX XXXXXXXXXXXXXXXXX 
xX BORROW/LOANS x x COST/CUSTOMER x 
x x x x 
XXXXXXXXXXXXXXXX XXXXX XXXXXXXXXXXX ) 
GHU "CUSTOMER 
*BORROW/LOANS ° STATUS CODE="pB* 
REPL STATUS CODE="by¥* 


The logical replace rule prevents replacing the LOANS segment as part 
of a concatenated segment, since replacement must be by the segment's 


physical path. 


However, the status code returned is 'BP'. 
segment, being accessed by its physical path, is replaced. 


The BORROW 
Since the 


access of the logical child is by its physical path, it does not matter 


what replace rule is selected. 


The LOGICAL replace rule provides for the special case of allowing 
the replacement of only the logical child half of the concatenation, and 


the return of a 'PBK*' status code. 
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RULES= (--V) 


RULES= (-~-V) 


KXXXXXXXXXXXX XXXXXXXXKXKXKXKX 
x CUSTOMER x x LOANS x 
x PP x x LP x 
XXXXXXXXXXXX *® XXXXXXXXXXXKX 
x * * V 
x a v 
XX XXXXXNKXNNK MXXKXKXXKXXKXX * * Vv 
x x * * Vv 
x x x“ ®t Vv 
XXX XXXXXXXKXX XXKXXXXXXXXX * VVVVVVVVVVVV 
x ACCOUNTS x xX BORROW x V cUST Vv 
x x x LC x Vv VLC v 
XXXXXXXXXXXX xX XXXXXXXXXX VVVVVVVVVVVV 
x RULES= (~-V) 
x 
XX XXXXXXXXXX 
xX PAYMENTS x 
x x 
XXXXXXXXXXXKX 
xXXXXXXXXXXX XXXXXXXXXXXX 
xX CUSTOMER x x LOAWS x 
x x x x 
XXXXXXXXXKXX XXXXXXXXXXXX 
x x 
x x 
XXKXXXXXXXXXXXKXX XXXXXXXXXXKXXXXXX 
xX BORROW/LOANS x x CUST/CUSTOMER x 
x x XK x 
XXXXXXXXXKXXKXXX XXXX¥XXXXXXXXXXXXX 
GHU "LOANS! 
*CUST/CUSTOMER'! STATUS CODE='ps' 


REPL 


STATUS CODE=" by' 


The virtual replace rule allows replacing the CUSTOMER segment via 
its logical path as part of a concatenated segment. 


Replace Rules Summary 


Specifying the replace rule as virtual, on any of the segments 


involved in the logical relationship, allows replacing that segment by 
either its physical path or logical path. 


Specifying the replace rule as physical, on any of the segments 
involved in the logical relationship, 


segment except when retrieved via its physical path. 
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The logical replace rule provides for a special case. Specifying the 
replace rule for the logical parent as LOGICAL, allows IMS/VS to return 

'ye' status code but without replacing any data when the logical 
parent is accessed concatenated with the logical child. Since the 
logical child has been accessed by its physical path, its replace rule 
may be any of the three. Thus using the LOGICAL replace rule allows the 
selective replacement of the logical child half of the concatenation and 
a "BW status code. 


Figure 4-33 shows all possible combinations of the replace rules that 
can be specified, and the resulting actions that take place for each 
combination when a call is issued to replace a concatenated segment in a 
logical data base. 


SEGMENT REPLACE RULES 
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Figure 4-33. Replace Rules 


4.70 IMS/VS System/Application Design Guide 





THE INSERT RULES 


Applicable to the Destination Parent (Logical Parent and Physical 
Parent) segments, but not to the Logical Child segment. See "Logical 
Child Insertion" below. 


1. PHYSICAL: The destination parent may be inserted only via its 


physical parent path. 


This means that the destination parent must exist prior to 
inserting a logical path. A concatenated segment is not needed; 
the logical child is inserted by itself. 


2. LOGICAL: The destination parent may be inserted either via its 


physical path or concatenated with the logical child via the 
logical path. 


When a logical child/destination parent concatenated segment is 
inserted, the destination parent is inserted provided it does not 
already exist and the I/0 area key check does not fail (see ‘DA* 
status code). If the destination parent does exist, it will 
remain unchanged and the logical child will be connnected to it. 


path or concatenated with the logical child via the logical path. 


3. VIRTUAL: The destination parent may be inserted via its physical 


When a logical child/destination parent concatenated segment is 
inserted, the destination parent is replaced if it already 
exists, and is inserted if it does not. 


Logical Child Insertion 


The RULES operand must be coded to supply replace and delete rules 
for the logical child. However, the insert rule has no meaning except 
to satisify the RULES macro's coding scheme, so any insert rule (P,L,V) 
may be coded. 


1. A logical child will be inserted provided that the insert rule of 
the destination parent is not violated, and 


2. The logical child to be inserted does not already exist (that is, 
is not a duplicate). 


The Insert Call 
The I/O area in an application program must contain either the 

logical child or the logical child/destination parent concatenated 

segment in accordance with the destination parent's insert rule. 


The logical child/destination parent concatenated segment insert 
operation is performed only if both components of the concatenated 
segment can be inserted. 


The insert operation is not affected by KEY or DATA sensitivity as 
specified in a logical DBD or a PCB. This means that if a program is 
other than DATA sensitive to both the logical child and the destination 
parent of a concatenated segment, that program must nevertheless supply 
both in the I/O area when inserting a logical path, and the insert rule 
is logical or virtual. Thus maintenance programs that insert 
concatenated segments should be DATA sensitive to both segments in the 
concatenation. 
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Status Codes 
‘ame - 
tcp - 
‘Tre - 





An insert was attempted and PROCOPT#I. 


Parent of the destination parent or logical child was 
not found. 


Attempt to insert duplicate segment. 

Physical rule and destination parent not found. 

I/O area key check fails. Concatenated segments 
contain the destination parent's key twice -- once as 


part of LCHILD's LPCK and second as a field in the 
parent. The keys must be equal. 


Physical Insert Rule Example 
RULES= (P--) ROULES= (P--) 
XXXXXXXXXXXX XXXXXXXXKXKXKY 
x CUSTOMER x x LOANS x 
x PP x x LP x 
XXXXXXXXXXXX m XXXXXXXKXXXXX 
x * * Vv 
x * m Vv 
XXXXXXXXXXXXXXXXXXXXKXXXX * * Vv 
x x * * Vv 
x x x « Vv 
XXXXXXXXKXXX XXXXXXXXXXKX * VVVVVVVVVVVY 
x ACCOUNTS x x BORROW x Vv cust v 
x x x LC x Vv VLC Vv 
XXXXXXXXXXXX XX XKXXXXXXxXxX VVVVVVVVVYVYV 
x ROLES= [(P--) 
x 
XXXEXXXXXXXX 
Xx PAYMENTS x 
x x 
XXXXXXXXXXXX 
XXXXXXXXXXXX XXXXXXXXXXXX 
xX CUSTOMER x x LOANS x 
x x x x 
XXXXXXXXXXXX XXXXXXXXXXXX 
x x 
x x 
XXXXXXXXXXXKXXXXX XXXXXXXXXXXXXXXXX 
X BORROW/LOANS x x CUST/CUSTOMER x 
x x x x 
XXXXKXXXXXXXXXXKX XXXXXXXXXXKXXKEXXX 


If the LOANS segment does exist then: 


ISRT ‘'CUSTOMER'® STATUS CODE='"Bp* 
ISRT ‘BORROW! 


STATUS CODE="By! 


However, if LOANS does not exist, then: 


ISRT ‘'CUSTOMER® STATUS CODE=' BK! 
ISRT BORROW! 


STATUS CODE="IXx! 
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Logical Insert Rule Example 


RULES= (L--) 


ROLES= (L--) 


xXXXXXXXXXXX XXXXXXXXXXXX 
x CUSTOMER x x LOANS x 
x PP x x LP x 
xXXXXXXXXXXx x XXXXXXXXXXXK 
x * x Vv 
x * * Vv 
XX KXXXXXXXXXX XXXXXXEXKXXXXX * x Vv 
x x * * Vv 
x x x * Vv 
XXXXXXXXXXXX XXXXXXKXKXXX * VVVVVVVVVYVV 
x ACCOUNTS x x BORROW x V CUST Vv 
x x Xx LC x Vv VLC v 
xXXXXXXXXXXX XX XXXXXXXXXX VVVVVVVVVVVV 
x RULES= [(L--) 
x 
XXXXXXXXXXXX 
X PAYMENTS x 
x x 
XXXXXXXXXXXX 
XKXXXXXXXXXXX XXXXXXXXXXXX 
Xx CUSTOMER x x LOANS x 
x x K x 
XXXXXXXXXXXX XXXXXXXXXXXX 
x x 
x x 
XXXXXXXXXXXXXXXKX XXX XXXXXXXXXXXXKXX 
x BORROW/LOANS x x CUST/CUSTOMER x 
x x x x 
XXKXXKXXXXXKXXXXXX XXXXXXXMKXXXXXXXXK 
ISRT ‘LOANS® STATUS CODE="pH' 
ISRT ‘cust! STATUS CODE="Ix'! 
The 'IxX' status code is the result of omitting the concatenated 


segment CUST/CUSTOMER in the second call. 
the CUSTOMER segment {in the I/O area) and failed to find it. 


IMS/VS checked for the key of 
With the 


logical insert rule, the concatenated segment must be inserted to create 


a logical path. 
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Virtual Insert Rule Example 


RULES= [V--) 


RULES= {V--) 


XXXXXXXXXXXX KXXXXXXXXXXXX 
x CUSTOMER x x LOANS x 
x PP x x LP x 
XXXXXXXXXXXX * XXYXXXXXXKXXKX 
x * * Vv 
x * * Vv 
XXXXXXXXXXXXXXXXXXXXXXXXX * * v 
x x * * Vv 
x x * Vv 
XXXXXXXKXXXKX XXXXXXXXXxxx * VVVVVVVVVVVYV 
x ACCOUNTS x x BORROW x Vv CUST Vv 
x x x LC x Vv VLC v 
xXXXXXXXXXXXX XXXXXXXXXXXX VVVVVVVVVVVV 
x ROULES= (V--) 
x 
XXX XXXXXXXXxX 
KX PAYMENTS x 
x x 
XXXXXXXXXXXX 
XXXXXXXXXXXxX XXXXXXXXXXXX 
x CUSTOMER x x LOANS x 
x x x x 
XXXXXXXXXXXX XXXXXXXXXXXX 
x x 
x x 
XXX XXXXXXXXXXXKXX XXXXXXXXKXXKXXXXX 
xX BORROW/LOANS x x CUST/CUSTOMER x 
x x x x 
XXXXXXRXXXXXXXXX XXXXXXXXXXXXXXXKXX 


ISRT "CUSTOMER® 


ISRT ‘'*BORROW/LOANS'* 


Remember this action will replace the LOANS segment if present, 


STATUS CODE=! py' 


STATUS CODE='Bp'* 





and 


insert the LOANS segment if not, so the virtual insert rule is a very 


powerful option. 
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Insert Rules Summary 

The virtual insert rule is the most powerful of the three rules in 
that it will insert the destination parent (inserted as a concatenated 
segment via the logical path) if the parent didn't previously exist, and 
replace the existing destination parent with the inserted destination 
parent otherwise. 


Specifying the insert rule as logical on the logical parent and the 
physical parent, allows insertion via either its physical path or its 
logical path as part of a concatenated segment. When inserting a 
concatenated segment, if the destination parent already exists, it will 
remain unchanged and the logical child will be connected to it. If it 
does not exist, it will be inserted. In either case, the logical child 
will be inserted provided that the segment is not a duplicate and that 
the destination parents insert rule is not violated. 


Specifying the insert rule as physical prevents inserting the 
destination parent as part of a concatenated segment. This means that a 
destination parent may be inserted only by its physical path. If the 
insert creates a logical path, only the logical child needs be inserted. 


DELETE RULES INTRODUCTION 


XXXXXXXXXXXX KXXXXXXXXXXX 
x CUSTOMER x x LOANS x 
x PP x x LP x 
XXXXXXXKXXXX * XXXXXXXXXXXX 
x * * Vv 
x ~ x Vv 
XX XXXXXXXKXKK KXXXXXXXXXXXX * * Vv 
x x * * Vv 
x x x * V 
XXXXXXXXXXXX KXXXXXXXXXXXX * VVVVVVVVVVVYV 
x ACCOUNTS x x BORROW x Vv CUST Vv 
x x x LC x Vv VLC v 
XXXXXXXXXXXX XX XXXXXXXXXxX VVVVVVVVVVVV 
x 
x 
XXXXXXXXXXXX 
X PAYMENTS x 
x x 
wXKXXXXXXXXXX 
PHYSICAL PATH PHYSICAL PATH 
TO CUSTOMER and BORROW TO LOANS 
XXXXXXXXXXXX Xx XXX XXXXXKXKX 
x CUSTOMER x x LOANS x 
x x x x 
MXXXXXXXXXXX XXXXXXXXXXXX 
x x 
x x 
XXXXXXXXXXXXXXXX XXXXXXKXXXKXXXXXX 
X BORROW/LOANS x x CUST/CUSTOMER x 
x x x x 
xXXXXXXXXXXXXXXYX XXXXXXXXXXXXXXXXX 
LOGICAL PATH LOGICAL PATH 
TO LOANS TO CUSTOMER and BORROW 
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The DLET call is a request for access path deletion not DASD space 
release of a segment. Delete rules are needed when a segment is 
involved in a logical relationship because that segment belongs to two 
paths; a physical path and a logical path. 


The selection of the delete rules for the logical child and its 
logical and physical parent (or two logical parents if physical 
pairing), determines whether one or two DLET calls are necessary to 
delete the two access paths. 


Physical and Logical Deletion 

1. PHYSICAL DELETION: Physically deleting a segment prevents 
further access to that segment via its physical parents. 
Physically deleting a segment also physically deletes its 


physical dependents. 


EXCEPTION: If one of the physical parents of the physically 
deleted segment is a logical child segment which has been 
accessed from its logical parent, then the physically deleted 
segment is accessible from that logical child since the physical 
dependents of a logical child are "Variable Intersection Data." 

2. LOGICAL DELETION: Logically deleting a logical child prevents 
further access via its logical parent. Unidirectional logical 
child segments are assumed to be logically deleted. 


A logical parent is considered logically deleted when all of its 
logical children are physically deleted. For physically paired 

logical relationships, the physical child paired to the logical 

child must also be physically deleted, before the logical parent 
is considered logically deleted. 


Deleting Concate 


Oncatenated Seqments 

The picture below shows that an application program can be sensitive 
to either the concatenated segment (SOURCE=(DATA/DATA), {DATA/KEY), 
(KEY/DATA) or only the logical child, since it is the logical child that 
is either physically or logically deleted [depending on the path 
accessed) in all cases. 
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XX XXKXXXXXXXX XXXXXXXKXKXKXKXX XXXXXXXXXXXX 
Xx CUSTOMER x x CUSTOMER x x CUSTOMER x 
x x x x x x 
XXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXXKXXKX 

x x x 

x x x 
XXXXXXXXXXXXXXKXKX XXEXKXXKXXKXX XXXXXXXXXXX¥X 
x BORROW/LOANS x X BORROW Xx x LOANS fx 
x x x x x x 
XXXXXXXXXXXXXXXKX XX XXXXXXXXXX XXXXXXXXXXXKX 
SOURCE= [DATA/DATA) (DATA/KEY) (KEY/DATA) 
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The Third Access Path 
XXXXXXXXXXXX XX XXXXXXXXXX XXXXXXXXXXXXK 
x x SEG! x xPDx SEG3 x *y x SEG7 x 
x x PP x x x PP x * ky X LP x 
XXXXXXXXXXXX XXXXXXXXXXXX * © XXXXXXXXXXXX 
x x x * Vv 
x x * * v 
XXXXXXXXXXXX XXXXXXXXXXXX* * VVVVVVVVVVVY 
x x SEG2 x XxPDx SEGY <x * Vv SEG8 v 
x x LC x*® xLDx LC x Vv VLC v 
XXXXXXXXXNXK * xXXXXXXXXXXX VVVVVVVVVVVY 
* x 
* x 
* XXXXXXXXXXXX 
x xPDx SEG5 x 
* x «x x 
* XXXXKXXXKXXXKXX 
* x 
* x 


* XXXXXXXXXXXX 
*x¥PDx SEG6 x 
x xX LP x 
XX XXXXXUKXXX 


There are three paths to the logical child segment SEG4&. The 
physical path from its physical parent SEG3, the logical path from its 
logical parent SEG7, and a third path from its physical dependents (SEG5 
and SEG6) because segment SEG6 is a logical parent accessible from its 
logical child SEG2. 


These paths are "full-duplex" paths, meaning that accessibility is 
two way (up and down). There are two delete bits that control access 
along the paths, but they are "half-duplex," meaning that they only 
block half of each respective path. There is not a bit that blocks the 
third path. If SEGY were both physically and logically deleted (PD and 
LD bits set), it would still be accessible from the third path and so 
would both of its parents. 


Neither physical nor logical deletion prevents access to a segment 
from its physical or logical children. Logically deleting SEG4 prevents 
access to SEG& from its logical parent SEG7, but does not prevent access 
from SEG4 to SEG7. Likewise, physically deleting SEG4 prevents access 
to SEG4 from its physical parent SEG3, but does not prevent access fron 
SEG4 to SEG3. 


DELETE BYTE DEFINITION 


segment Prefix Delete Byte 


The delete byte is used by IMS/VS to maintain the delete status of 
segments within a data base. The meaning of each bit within the delete 
byte is shown in Figure 4-2. 


The logical delete bit is only meaningful for logical child segments 
and their logical parents. The PD and LD bits are set or assumed set as 
follows: 


e If a segment is physically deleted [prevent further access from its 


physical parent), then delete processing scans downward from that 
segment through its dependents, turns upward and either releases 
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each segment's DASD space or sets the PD bit. HISAM is an exception -- 
the delete bit is set in the segment specified by the DLET call and 
processing terminates. 


e If the PD bit is set in a logical parent, then the LD bit is set in 2 
all logical children that can be reached from that logical parent. 


e In physical pairing when the PD bit is set in the physical child of 
a pair of logical children, the LD bit is set in its pair. 


e When a virtually paired logical child segment is logically deleted 
(prevent further access from its logical parent), the LD bit is set 
in the logical child. If physical pairing, the LD bit is set in the 
logical child and the PD bit is set in its pair (a physical child of 
the logical parent). 


e The LD bit is assumed to be set in all logical children of 
unidirectional logical relationships. 


e The LD bit is assumed set in a logical parent when the PD bit is set 
in all of its logical children. If physical pairing, the PD bit 
must be set in both paired logical children. 


The Delete Call 


A DL/I delete call may be issued against a segment defined in either 
a physical or logical DBD. The call can be issued against either a 
physical segment or a concatenation. 


A delete call issued against a concatenated segment is a request for 
the deletion of the logical child along the accessed path. 


If a concatenated segment or a logical child is accessed from its ) 
logical parent, then the DLET call is a request for logical deletion. 
In all other cases, a DLET call is a request for physical deletion. 


Physical deletion of a segment propagates logical deletion request to 
its logical children and propagates physical deletion request to its 
physical children and to any index pointer segments for which it is the 
source segment. 


Celete sensitivity must be specified in the PCB for each segment 
against which a DLETI call may be issued, but need not be specified for 
the physical dependents of those segments. 


Delete operations are not affected by KEY/DATA sensitivity as 
specified in either the PCB or logical DBD. 


Status Codes 


Dx* - A delete rule is violated 


"Dat - Key changed in the I/0 area 
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DASD SPACE RELEASE 


The delete call is not a reguest for DASD space release. Depending 


on the data base organizaticn, DASD space may or may not be reused when 
it is released. DASD space for a segment is released when the following 
conditions are met: 


Space has been released fcr all physical dependents of the segment. 
The segment is physically deleted (PD bit set or being set). 


If the segment is a logical child or a logical parent, then it must 
be physically and logically deleted (PD bit set/being set, and ID 
bit set/assumed set). 


If the segment is a dependent of a logical child (variable 
intersection data) and the DLET call was issued against a physical 
parent of the logical child, then the logical child must be both 
physically and logically deleted. 


If the segment is a primary index pointer segment, the space has 
been released for its target segment. 


DELETE RULES 


Ogical Parent 


1. PHYSICAL: The logical parent must be previously logically 
any of its physical parents. Otherwise the call results in a 
"DX" status code and no segments are deleted. 


However, if a delete request is made against the segment as a 
result of propagation across a logical relationship, then the 
PHYSICAL rule acts like the following LOGICAL rule. 


2. LOGICAL: Either physical cr logical deletion can occur first. 


When the logical parent is processed by a DLET call, all logical 
children are logically deleted, but the logical parent continues 
to be accessible from its logical children. 


3, VIRTUAL: A logical parent will be deleted along its physical 


® Explicitly when deleted by a DLET call. All of its logical 
children are logically deleted although the logical parent 
remains accessible from these logical children. 


@ Implicitly when it is no longer involved in a logical 
relationship. A logical parent is no longer involved ina 
logical relaticnshif when: 


- It has no logical children pointing to it (its 
logical-child counter is zero, if it has any), and 


= It points tc no logical children (all of its 
logical-child pcinters are zero, if it has any), and 


= It has no physical children that are also real logical 
children. 
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1. PHYSICAL/LOGICAL/VIRTUAL: Meaningless 


2- BIDIRECTIONAL VIRTUAL: The physical parent will be automatically 
deleted along its physical path when it is no longer involved in 
a logical relationship. The physical parent is no longer 


involved in a logical relationship whens 


@ It has no logical children pointing to it {its logical-child 
counter is zero, if it has one), and 


e It points to no logical children (all of its logical-child 
pointers are zero, if it has any), and 


e It has no physical children that are also real logical 
children. 


1. PHYSICAL: The logical child segment must be logically deleted 
first and physically deleted second. If physical deletion is 
attempted first, the DLET call issued against the segment or any 
of its physical parents results ina 'DX' status code and no 
segments are deleted. If a delete request is made against the 
segment as a result of propagation across a logical relationship, 
or if the segment is one of a physically paired set, then the 
rule acts like the following LOGICAL rule. 


2. LOGICAL: Deletion of a logical child is effective for the path 
for which the delete was requested. Physical and logical 
deletion of the logical child can be performed in any order. 


The logical child and any physical dependents remain accessible 
from the non-deleted path. 


3. VIRTUAL: A logical child is both logically and physically 
deleted when it is deleted through either its logical or physical 
path {setting either the PD or LD bits, sets both). If this rule 
is coded on only one logical child segment of a physically paired 
set, it acts like the LOGICAL rule. 


For logical children involved in unidirectional logical 
relationships, the meaning of all three rules are the same, so any of 
the three rules can be specified. 

EXAMPLES 

The following examples illustrate the use of the delete rules 

individually for each of the segment types that the rule can be coded 


for (logical children, and their logical and physical parents). 


Only the rule pertinent to the examples are shown in each figure. 
The explanation applies to the specific example. 
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Logical Child, Virtual Pairing -- Physical Delete Rule Example 


XXXXXXXXXXXX 
RULES= (---) x CUSTOMER x 
x PP x 
xXXXXXXXXXXX 
x 
x 
XXXXXXXXXKXXXXKXXXXX 
x 
x 
XXXXXXXXXXXX 
x ACCOUNTS x 
x x 
XXXXXXXXXXXX 


To Delete the Logical Child 


XxXXXXXXXXXXXXXX 
x x LOANS x 
x x x 
XXXXXXXXKXXXXXX 

x 

x 
XXXXXXXXXXXXXXXKXXXX 
x x CUST/CUSTOMER x 
xLDx x 
XXX XXXXXXXXXXXXXXXXX 


XXXXXXXXXKXXXXXX 
x x CUSTOMER x 
x x x 
XXXXXXXXXXXXXXX 

x 

x 
XXXXXXKXXXXXXXXXXXXXX 
XPDx BORROW/LOANS x 
xLDXx x 
xXXXXXXXXXXXXXXXXXXX 

x 

x 
XXXXXXXXXXXXXXX 
XPDx PAYMENTS x 
x x x 
KXXXXXXXXXXXXXXK 


XXXXXXXXXXXX 
RULES= (---)x LOANS x 
x LP x 
* XXXXXXXXXXXX 
* * Vv 
ae * v 
XXXXXX * * Vv 
x * * V 
x * * Vv 
XXXXXXXXXXXX * VVVVVVVVVVVV 
x BORROW x Vv CUST v 
x LC x Vv VLC v 
XXXXXXXXXXXX VVVVVVVUVVVY 
xX RULES=(-P-) 
x 
XXXXXXXXXXXX 
Xx PAYMENTS x 
x x 
XX XXXXXXXXXX 
GHU "LOANS? 
'CUST/CUSTOMER'® STATUS='! BBE 
DLET STATUS=" Bp 


The physical delete rule requires the 
logical child be logically deleted 
first. The LD bit is now set in 

the BORROW segment. 


GHU "CUSTOMER! 
*BORROW/LOANS' STATUS=' py' 


DLET STATUS=" bp? 


The logical child can be physically 
deleted only after being logically 
deleted. After the second delete, 
both the LD and PD bits are set. 


The physical delete of the logical 
child also physically deletes the 
physical dependents of the logical 
child. The PD bit is set. 
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XXXXKXXXXXXXX KXXXXXXXXKXXX 
RULES=(--~-)x CUSTOMER x ROLES= (---)x LOANS x 
x PP x x LP x 
XXXNXXXXXXXXX m XXXKNXXXXXXX 
x * * Vv 
x * * Vv 
XXXXXXXMXXXKRKXKKXXXXXXXXXX * * Vv 
x x * * v 
x x x * Vv 
XXXXXXXXXXXX XXXXXXXXXXXx * VVVVVVVVVVVYV 
x ACCOUNTS x x BORROW x Vv CUST Vv 
x x x LC x Vv VLC v 
XXXXXXXUXXXX XXXXXXXXXXXX VVVVVVVVVVVYV 
x RULES=([-L-) 
x 
XX XXXXXXXXXKX 
X PAYMENTS x 
x x 
XXXXXXXXXXLXX 
To Delete the Logical Child 
XXXXXXXXKXXXXXXX GHU "CUSTOMER!' 
x x CUSTOMER x "BORROW/LOANS'! STATUS=' pp! 
x xX x 
XXXXXXXXXXXXXXX DLET STATUS=" bp 
x 
x 
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XXXXXEXXXXXXXXXXXXXXX 
xPDx BORROW/LOANS x 
x XX x 
XXXXXXXXKXXKXAXXXKXKXXX 
x 
x 
XXXXXXXXKKXXXKXX 
XPDx PAYMENTS x 
x Xx x 
XXXXXXXXXXXKXXKX 


XXXXXXXXKXXXXXX 
x x LOANS x 
x xX x 
XXXXXXXXXXXXXXX 

x 

x 
XXXXXXXXXXKXXKXXXXXXX 
xPDx CUST/CUSTOMER x 
xLDx x 
XXXXXXXXXXXXXXXXXXXX 


IMS/VS System/App 


The logical delete rule allows the 
logical child to be deleted 
physically or logically first. 


Physical dependents of the logical 
child are physically deleted, but 
remain accessible from the logical 
path not logically deleted. 


GHU "LOANS! 

'CUST/CUSTOMER!® STATUS='! pp 
DLET STATUS='BPP! 
The delete of the virtual logical 
child sets the LD bit on, in 


the physical logical child BORROW 
(BORROW is logically deleted) 
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Logical Child, Physical Pairing -- Physical/Logical Delete Rule Example 


XXXXXXXXXXXXXXX 
x x CUSTOMER x 
x x x 
XXXXXXXXXXXXXXX 

x 

x 
XXXXXXXXXKXXXXNXXKKXX 
XPDx BORROW/LOANS x 
x Xx x 
XXXXXXXXXXXXXXXXXXXX 

x 

x 
KXXXXXXXXXXXXXXX 
XPDxX PAYMENTS x 
x x x 
XXXXXXXXXXXXUXKX 


xXXXXXXXXXXXXXX 
x x LOANS x 
x x x 
MXKKXKXKXXKKXXXX 

x 

x 
XXXXXXXXXKXXXXXXXXXXX 
XxPDx CUST/CUSTOMER x 
xLDx x 
XXKXXXXXXXKXXXKXXKXX 


XXXXXXXXXXXKX XXXXXXXXKXXXX 
RULES= (---) x CUSTOMER x RULES= (---)x LOANS Xx 
x LP x x LP x 
XXXXXXXXXXxX * XXXXXXXXXXXX 
x * x 
x * * x 
xXXXXXXXXXXXXXXXXXXXXXXXX * * x 
x x * * x 
x » 4 * x 
XXXXXXXXXXXX XXXXXXXXXXXX * * XXXXXXXXXXXX 
x ACCOUNTS x x BORROW x * Xx CUST x 
x x LC x x LC x 
XXXXXXXXXXXX XXXXXXKXXXXX XXXXXXXXXXXX 
x RULES=(-P-) RULES= [(-P-) 
x -L- -L- 
XXXXXXXXXXXX 
X PAYMENTS x 
x x 
XXXXXXXXXKXKXX 
Qo Delete the Paired Logical Children 


GHU "CUSTOMER! 
*BORROW/LOANS' STATUS=* bY* 


DLET STATUS=' by' 


With the physical or logical delete 
rule, each logical child must be 
deleted from its physical path. 


Physical dependents of the logical 
child are physically deleted, but 

remain accessible from the paired 

logical child not deleted. 


GHU "LOANS! 
*CUST/CUSTOMER* STATUS=* b* 


DLET STATUS=* Bp! 


Physically deleting BORROW set 
the LD bit in CUST. Physically 
deleting CUST will set the LD 
bit in the BORROW segment. 
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Logical Child, Virtual Pairing -- Virtual Delete Rule Example 


XXXXXXXXXXXX 


RULES=(---)x CUSTOMER x 
x PP x 
XXXXXXXXXXxXxX 

x 
x 
XXXXXXXXXXXXXXXXXXX 
x 
x 
xxXxxXxXXXXxxxxxX 
x ACCOUNTS x 
x x 
XXXXXXXXXXXX 


To Delete the Logical Child 


XXXXXXXXXXXXXXX 
x x CUSTOMER x 
x xX x 
XXXXXXXXXXXXXXX 

x 

x 
XXXXXXXXXXXXXXXXXXXX 
xPDx BORROW/LOANS x 
xLDx x 
XXXXXXXXXXXXXXXXXXXX 

x 

x 
XXXXXXXXXXXXXXX 
xPDx PAYMENTS x 
x x x 
XXXXXXXXXXXXXXX 


XXXXXXXXXXKXXXXX 
xX x LOANS x 
x x x 
XXXXXXXXXXXXXXX 

x 

x 
XXXXXXXXXXXXXXXXXXXX 
xPDx CUST/SCUSTOMER x 
xLDx xX 
XXXXXXXXXXXXXXXXXXXX 
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XXXXXXXXXXKXX 
RULES= (--~-)x LOANS x 
x LP x 
m XXXXXXXXXXXX 
x * v 
* ae Vv 
XXXXXX * * Vv 
x * * Vv 
x * * Vv 
XXXXXXXXXX¥XX * VVVVVVVVVVVY 
x BORROW x Vv cust Vv 
x LC x Vv VLC v 
XXXXXXXXXXXX VVVVVVVVVYVV 
x RULES=(-V-) 
x 
XXXXXXXXXXXX 
X PAYMENTS x 
x x 
XXXXXXXXXXXX 
GHU "CUSTOMER! 
*BORROW/LOANS! . STATUS=' py 
DLET STATUS=' MB! 


The virtual delete rule allows the 
logical child to be deleted 
physically and logically. Deleting 
either path, deletes both paths. 


Physical dependents of the logical 
child are physically deleted. 


GHU "LOANS! 
'CUST/CUSTOMER'® STATUS='GE* 


The previous physical delete, 
deleted both paths, because the 
delete rule is virtual. Deleting 
either path, deletes both. 
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XXXXXXXXXXXX XXXXXXXXXKXX 
RULES=(---)x CUSTOMER x RULES={[---)x LOANS x 
x LP x x LP x 
XKXXXXXXXXXxX * XXXXXXXXXXXX 
x * * x 
x * * x 
XXXXXXXXXXXXKXXKKXXKKXXXXXX x * x 
x x * * x 
x x * x 
XXXXXXXXXXXX XXXXXXXXXXXXK * * XX XXXXXXXXXX 
x ACCOUNTS x x BORROW x * x cUSsT x 
x x x LC x x LC x 
XXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXXXXXX 
x RULES=(-V-) RULES= (-V-) 
x 
XRXXXXXXXXXX 
x PAYMENTS x 
x x 
XXXXXXXXXXKXX 


To Delete the Paired Logical Childre 


XXXXXXXXXXXXXKX 
x x CUSTOMER x 
x x x 
XXXXXXXXXXKXXXX 

x 

x 
XXXXXXXXNKXKKKKXXXXX 
xPDx BORROW/LOANS x 
xLDx x 
XXXXXXXXXXXKKXXXXXXX 

x 

x 
XXXXXXXXXXXXXXX 
XPDx PAYMENTS x 
x x x 
XxXXXXXXXXXXXKXX 


XXXXXXXXXXXAXXXX 
x x LOANS x 
x x x 
XXKXXXXXKXXXXXX 

x 

x 
XXXXXXXXXXXXXXXXXXKXX 
xPDx CUST/CUSTOMER x 
xLDx x 
XXXXXXXXXXXXXXXKXXXX 


GHU "CUSTOMER! 


*BORROW/LOANS'§ STATUS=* By! 


DLET STATUS=* by! 


With the virtual delete rule, 
deleting either logical child deletes 
both paired logical children. 

(notice the PD & LD in both) 


Physical dependents of the logical 
child are physically deleted. 


GHO "LOANS * 


*CUST/CUSTOMER® STATUS="GE* 


Physically deleting BORROW also 
physically deleted CUST, so the 
CUST segment was not found, 
that is, ‘GE status code. 
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XXXXXXXXXXXX XXXXXXXXXXxXX 
RULES={[{---)x CUSTOMER x RULES= (-P-)x LOANS x 
x PP x x LP x 
XXXXXXXXXXXX *® XXXXXXXXXXXX 
x x * v 
x * * Vv 
XXXXXXXXXXXXXXXXXXXXXKXXXX * * Vv 
x x me * Vv 
x x *¥ * Vv 
xxEXXXXXXXXX MXXXXXXXNXXXX *. VVVVVVVYVVVVV 
x ACCOUNTS x x BORROW x Vv CUST Vv 
x x x LC x Vv VLC Vv 
KXXXXXXXXXXX XXXXXXXXXXXX VVVVVVVVVVVV 
x RULES=(---) 
x 
XXXXXXXXXxXX 
X PAYMENTS x 
x x 
XXXXXXXXXXXX 
To Delete the Logical Parent 
"BEFORE*® 
XXXXUNXKXXXXXXXX GHU "LOANS? STATUS=' wR! 
x x LOANS xX 
x xX x DLET STATUS=' Mp! 
XXXXXXXXXXXXXXX 
x 
x 


XXXXXXXXXXXXXXXXXXXX 
xPDx CUST/CUSTOMER x 
x x x 
XXXXXXXKXXXXAXXXXXKXX 


"AFTER" 
XXXXXXXXXXXXXXXK 
xPDx LOANS x 
x xX x 
XXXXXXXXXXXXXXX 

x 

x 
XXXXXXXXNXXKMKXXXXXX 
xPDx CUST/CUSTOMER x 
xLDx x 
KXXXXXXXXXXXXXXXXXXX 


The physical delete rule requires 
that all logical children be 
previously physically deleted. 


Physical dependents of the logical 
parent are physically deleted. 


Tne DLET status code will be 'DxX' 
if all of its logical children 
were not previously physically 
deleted. 


All logical children are logically 
deleted. LD bit is set in the 
physical logical child BORROW. 
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Logical Parent, Physical Pairing -- Physical Delete Rule Example 


XXXXXXKKXXXX 
RULES=(-P-)x CUSTOMER x 
x LP x 
XXXXXXXXXXXX 
x 
x 
XXXXXXXXXKEXXXXXXXX 
x 
xX 

XXXXXXXXXXXX 

x ACCOUNTS x 

x x 

XXXXXXXXXXXX. 

Zo Delete Either of the 
"BEFORE" 
XXXXXXXXXXXKXXKX 
x x CUSTOMER x 
x xX x 
XXXXXXXXXXXXXXX 

xX 
xX 


XXXXXXXXKXXXXXXXXXXX 
XPDx BORROW/LOANS x 
xXxLDx x 
XXXXKXXXXXXXXXXXXXXX 


"AFTER" 
XXXXXXXXXXXXXXX 
XPDx CUSTOMER x 
x Xx x 
XXXXXXXXXXXXXXX 

x 

x 
XXXXXXKKXXXXXXXXXXXX 
xXPDx BORROW/LOANS x 
xLDx x 
XXXXXXXXXXXXXXXXXXXX 

x 

x 
XXXXXXXXXXXXXXX 
xPDx PAYMENTS x 
x XxX x 
KXXXXXXXXKXKXXX 


XXXXXXXXXXXX 
RUOLES=(-P-)x LOANS x 
x LP x 
* XXXXXXXXXXXX 
* * xX 
* ae xX 
XXXXXX * * x 
x * * x 
x * x 
XXXXXXXXXXXK * * XXXRXXXXXXXX 
x BORROW x * xX cust x 
x LC x x LC x 
XX XXXXXXXXXX XXXXKXXXXXXX 
Xx ROLES= (---) RULES= (---) 
X 
XXXXXXXEXXXX 
X PAYMENTS x 
x x 
XXXXXXXXXXXX 
Logical Parents 


GHU "CUSTOMER'S STATUS=* by' 


DLET STATUS=* bye 


The physical delete rule requires; 

(1) all Logical children to be 
previously physically deleted. 

(2) physical children paired to its 
logical child to be previously 
physically deleted. 


CUSTOMER, the logical parent 
has been physically deleted. 


Both the logical child and its pair 
had previously been physically 
deleted. (PD and LD set on in the 
"BEFORE" figure of BORROW/LOANS) 


All physical dependents of the 
physical parent are physically 
deleted; ACCOUNTS (not shown) 
is physically deleted. 
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XXXXXXXXXXXX 
RULES=(--~) x CUSTOMER x 
x PP x 
XXXXXXXXXXXX 
x 
x 
XXXXXXXXAXXKXKXXXIXX 
x 
x 
XXXXXXXXXXXX 
x ACCOUNTS x 
x x 
XXXXXXXXXXKXX 


To Delete the Logical Pa 


"BEFORE® 
XXXXXXXXXXXXXXX 
x x LOANS x 
x x x 
XXXXXXXXXXXXXXX 

x 

x 
XXXXXXXXXXXXXXXXXXXKX 
x x CUST/CUSTOMER x 
x x x 
XXXXXXXXXXXXXXXXKXXXX 


WAFTER® 
XXXXXXXXXXXXXXX 
XxPDx LOANS x 
x x x 
XXXXXXXXXXXXXXX 

x 

x 
XXXXXXXXXXXXXXXKXXXXX 
x x CUST/SCUSTOMER x 
xLDx x 
XXXXXXXXXXXXXXXXXXXX 


The above processing 
parent LOANS delete rule 
example to explain the v 
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Pairing -- Logical Delete Rule Example 


XXXXXXXXXXXX 
RULES= [(-L-)x LOANS xX 
x LP x 
* XXXXXXXXXXEX 
a * v 
a bd Vv 
XXXXXX * * Vv 
x * * Vv 
x * * Vv 
XXXXXXXNXXXXX * VVVVVVVVVVVYV 
x BORROW x Vv cust Vv 
x LC x v VLC v 
XXXXXXXXXXXX VVVVVVVVVVVY 
x RULES=[---) 
x 
XXXXXNXXXXXXX 
X PAYMENTS x 
x x 
XXXXXXXXXXXX 


rent 


GHO "LOANS' STATUS='"yye' 


DLET STATUS= "pt 


The Logical delete rule allows 
either physical or logical deletion 
first; neither causes the other. 
Physical dependents of the logical 
parent are physically deleted. 


The logical parent LOANS remains 
accessible from its logical 
children. 


All logical children are logically 
deleted. LD bit is set in the 
physical logical child BORROW. 


and results would be the same if the logical 
were virtual instead of logical. An additional 
irtual delete rule follows. 
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Logical Parent, Physica] Pairing -- Logical Delete Rule Example 


XXXXXXXXXXXX KXXXXXXXXXXXX 
RULES= {-L-) x CUSTOMER x RULES= (-L-)x LOANS x 
x LP x x LP x 
XXXXXXXXXXxXx * XXXXXXXXXXXX 
x * x 
x * * x 
XXXXXXXXXXXXXXXXXXXXXXXXX * x 
x x * * x 
x x * x 
XXXXXXXXXXXX XXXXXXXXXXXX * * XXXXXXXXXXXX 
x ACCOUNTS x x BORROW Xx * «x cust x 
x x x LC x x LC x 
XXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXXKXKXX 
x ROLES={(---) RULES= [---) 
x 
xX XXXXXXXXXX 
x PAYMENTS x 
x x 
XX XXXXXXXXXX 
To Delete Either of the Logical Parents 
"BEFORE" 
XXXXXXXXXXXXXXX GHU *"LOANS® STATUS=' pt 
x x LOANS x 
xX x x DLET STATUS=' By 
XXXXXXXKXXXXXXX 
x 
x 
XXXXXXXXXXXXXXXXXXXX The logical delete rule allows 
x x CUST/CUSTOMER x either physical or logical deletion 
Xx Xx x first; neither causes the other. 
XXXXXXXXXXKXXXXKXXXX Physical dependents of the logical 
parent are physically deleted. 
“VAFTER" 
XXXXEXXXXXXXXXX The logical parent LOANS remains 
xPDx LOANS x accessible from its logical 
x xX x children. 
XXXXXXXXXXXXXXX 
x 
x 
XXXXXXXXXXXXXXKXXXXXX All physical children are physically 
xPDx CUST/CUSTOMER x deleted. Paired logical children 
x x x are logically deleted. 


XXXXXXXXXXXXXKKXKKKX 


The above processing and results would be the same if the logical 
parent LOANS delete rule were virtual instead of logical. An additional 
example to explain the virtual delete rule follows. 
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xxXXXXXXXXXXX XxXXXXXXXXXXX 
RULES={---) x CUSTOMER x RULES=[(-V-)x LOANS x 
x PP x x LP x 
KKXKXEXXXXXXXX * XXXXXXXXXXKXX 
x mx * Vv 
x * * Vv 
XXXXXXXXXXXXXXXXXXXKXXXXXX * * Vv 
x » 4 * * Vv 
x x * * Vv 
XXXXXXXXXXXX XXXXXXXX¥XXXXK * VVVVVVVVVUVY 
x ACCOUNTS x x BORROW x V CUSsT Vv 
x x x LC x Vv VLC v 
XXXXXXXXXXXX XXX XXXXXXXKX VVVVVVVVVVVV 
x RULES= (---) 
x 
XXXXXXXXXXXX 
X PAYMENTS x 
x xX 
XXXXXXXXXXXX 


Deleting Last Logical Child Deletes Logical Parent 


4.90 


“BEFORE 
XXXXXXXXXXXXXXX 
x x CUSTOMER x 
x x x 
XXXXXXXXXXXXXXX 

x 

x 
XXXXXXXXXXXXEXXXXXXX 
x xX BORROW/LOANS Xx 
x x x 
XXXXXXXXXXXXEXXXXXXX 


"AFTER" 
KXXXXXXXXXXXXXX 
xPDx LOANS x 
x x x 
XxXXXXXXXXXXXXXX 

x 

x 
XXXXXXXXXXKXXXXXXXXX 
xPDx CUST/CUSTOMER x 
xLDx x 
xxxxxxxxxXxxXxXxxxXXxxXx 
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GHU "CUSTOMER® 
*BORROW/LOANS' STATUS='! pre 


DLET STATUS=' By'* 


The virtual delete rule allows 
explicit and implicit deletion. 


Explicit is same as logical rule. 


Implicit means the logical parent 
is physically deleted when the last 
logical child is physically deleted. 


Physical dependents of the logical 
child are physically deleted. 


The logical parent is physically 

deleted. Physical dependents of 

the logical parent are physically 
deleted. 


All logical children are logically 
deleted. LD bit is set in the 
physical logical child BORROW. 
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Logical Parent, Physical Pairing -~ Virtual Celete Rule Example 
XXXXXXXXXXXX XXXXXXXXXXXX 
RULES=(-V-)x CUSTOMER x RULES=[-V-)x LOANS xX 
x LP x x LP x 
XXXXXXXXXXxx * XXXXXXXXXXXX 
x * * x 
x * * x 
XXXXXXXXXKXKXXXXXNXXXXKXXX * * x 
x x * * x 
x x * x 
XXXXXXXKXXXX XXXXXXXXXXXX * * XXXXXXXXXXKXX 
x ACCOUNTS x x BORROW x * x cust x 
x x x LC x x LC x 
xXXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXXXXKXX 
xXx RULES= (---) RULES= (---) 
x 
XX XNXXNXXXXX 
X PAYMENTS x 
x x 
xxXXXXXXXXXX 


“BEFORE® 
XXXXXXXXXXXXXXX 
x x CUSTOMER x 
xX x x 
XXXXXXXXXXXXXXX 

x 

x 
XXXXXXXXXXXXXXXXXXXX 
Xx xX BORROW/LOANS <x 
xLDx x 
XXXXXXXXXXXXXXXXXXXX 


WAFTER" 
XXXXXXXXXXXXXXX 
xPDx LOANS x 
x x x 
xXXXXXXXXXXXXXXX 

x 

x 
XXXXXXKXXXXXXXXXXKXXXX 
xPDx CUST/CUSTOMER x 
xLDx - x 
XXXXXXXXXNXXXXXXXXXXX 


GHU "CUSTOMER ® 


"BORROW/LOANS'! STATUS=" pp! 


DLET STATUS=" by! 


The virtual delete rule allows 
explicit and implicit deletion. 


Explicit is same as logical rule. 


Implicit means the logical parent 
is physically deleted when the last 
logical child is physically and 
logically deleted. Physical 
dependents of the logical 

child are physically deleted. 


The logical parent is physically 
deleted. Any physical dependents 
of the logical parent are 
physically deleted. 


NOTICE CUST segment must have 
physically deleted prior to the 
DLET call. (See above that the 
LD is set in BORROW) 
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XXXXXXXXXXXX 
RULES= (-B-) x CUSTOMER x 
x PP x 
XXXXXXXXXXXX 
x 
x 
XXMNXXKXXXXXXXXXXXXX 
x 
x 
XXXXXXXXXXXX 
x ACCOUNTS x 
x x 
XXXXXXXXXXxXX 





Pairing -- Bidirectional Virtual Example 


XXXXXXXXXXXX ) 
RULES= (-~--)x LOANS x 
x LP x 
* XXXXXXXXXXXX 
5 * Vv 
sd i v 
XXXXXX * = Vv 
x * * v 
x * & Vv 
XXXXXXXXXXXX * VVVVVVVVVVVY 
x BORROW x v cust v 
x LC x Vv VLC v 
XXXXXXXXXXXX VVVVVVVVVVVY 
x RULES=(---) 
x 
XXXXXXXXXxXXX 
x PAYMENTS x 
x x 
XXXXXXXXXXXX 


Deleting Last Logical Child Deletes Physical Parent 


"BEFORE" 
XXXXXXXXXXXXXXX 
x x LOANS x 
x x x 
XXX XXXXXXXXXXXX 

x 

x 
XXXXNXXEXXXKXXXXXXXXX 
x x CUST/CUSTOMER x 
x x x 
XXXXXXXXXXXXXXXXKXXX 


"AFTER" 
MXXXXXXXXKXXXXX 
xPDx CUSTOMER x 
x x x 
xXXXXUKXKXXXXXXX 
x 
x 
XXXXXXXXXXXXXXXXKXXXKX 
XPDx BORROW/LOANS x 
xLDx x 
XXXXXXXXXXXXXKXXXXXX 
x 
x 
XXXXXNXXXXXXKEKXX 
xPDx PAYMENTS x 
x x X 
xX XXXXXXKXXXXXX 
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GHU "LOANS! 


"*CUST/C USTOMER® 


DLET 


The bidirectional virtual rule for 


STATUS=' PP! 


STATHS= "Bp! 


the physical parent, is equal to 
virtual for the logical parent. 


When the last logical child is 


logically deleted, the 


physical 


parent is physically deleted. 


The logical child 


{as a dependent of 


the physical parent) is physically 


deleted. 


All physical dependents of the 
physical parent are physically 


deleted; ACCOUNTS [not 
BORROW and PAYMENTS. 
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shown), 





A physically deleted segment remains accessible under the following 
circumstances; 


1. <A physical dependent of the deleted segment is a logical parent 
which is accessible from its logical children. 


2. A physical dependent of the deleted segment is a logical child 
which is accessible from its logical parent. 


3. A physical parent of the deleted segment is a logical child which 
is accessible from its logical parent. The deleted segment is 
this case is variable intersection data of a bidirectional 
logical relationship. 


A logically deleted logical child cannot be accessed from its logical 
parent. 


Neither physical nor logical deletion prevents access to a segment 
from its physical or logical children. Since logical relationships 
provides for inversion of the physical structure, a segment may be 
either physically or logically deleted or both and still be accessible 
from a dependent segment, because of an active logical relationship. A 
physically deleted root segment can be accessed when it is, defined as a 
dependent segment in a logical DBD. The logical DBD defines the 
inversion of the physical DBD. 
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dependent of a deleted segment is a logical parent with logical 
children not physically deleted, the logical parent and its 


physical parents are accessible from those logical children. ) 
XXXXXXXKXXXXX XXXXXXXXXXXX XXXXXXXXXXXX 
x x SEGIt x xPDx SEG3 x *x x SEG7 x 
x x PP x x <x PP x * x X LP x 
XXXXXXXXKXXXX XXXXXXXXXKXX * 8 XXXXXXXXXXXX 
x x x ® Vv 
x x x * v 
XXXXXXXXXXXX RXNXXXXXXXXX* * VVVVVVVVVVVYV 
x x SEG2 x xPDx SEGH x * v SEG8 ¥ 
x x LC x* x xX LC x Vv VLC v 
XXXXXXXXXXXX * XXXXXXXXXXXX VVVVVVVYVIVY 
* x & 
* x 
* " XXX XXXXXXXXX 
* xPDx SEGS x 
* x x x 
* XXXXXXNXXXXXX 
* x 
* x 


* XXXNXXXXXXXYX 
*xPDx SEG6 x 
x xX LP x 
XXXXXXXXXXXX 


The above physical structures show that SEG3, SEG4, SEG5S, and SEG6 
have been physically deleted. Probably by issuing a DLET call for SEG3. 
This resulted in all of SEG3"s dependents being physically deleted. 
(SEG6's delete rule # PHYSICAL or a "DX" status code would be the J 
result). 


SEG3, SEG4, SEG5, and SEG6 remain accessible from SEG2, the logical 
child of SEG6, because SEG2 is not physically deleted. 


However, physical dependents of SEG6 cannot be accessible, and their 


DASD space is released unless an active logical relationship prohibits 
such release. 
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2. EXAMPLE OF DELETED SEGMENTS ACCESSIBILITY: When the physical 
dependent of a deleted segment is a logical child whose logical 
parent is not physically deleted, the logical child, its physical 
parents and its physical dependents are accessible from the 


logical parent. 


KXXXXXXXXXXX XXXXXXXXXXXX XXXXXXXXXXXX 
x x SERGI «x xPDx SEG3 x *x x SEG? x 
x xX PP x x xX PP x * *x Xx LP x 
XXX XXXXXXXXX XXXXXXXXXXXX * * XXXXXXXXKXXXX 
x x * * Vv 
x x * * Vv 
XXXXXXXXXXXX XXXXXXXXXXXX* * VVVVVVVUVYVVY 
X x SEG2 x xPDx SEGUY x * v SEG8 v 
x x LC x*¥ x x LC x Vv VLC v 
XXXXXXXXXXXX * XXXXXXXXXXXX VVVVVVVVVVVV 
* x 
* x 
* KXXXXXXXXXXXX 
* xPDx SEG5 x 
* x x x 
* XXXXXXXXXXXX 
* x 
* x 


* XXXXXXXXXXXX 
*xPDx SEG6 x 
x x LP x 
XXXXXXXXKXXX 


The above physical structures show that SEG3, SEG4U, SEG5, and SEG6 
have been physically deleted. 


The logical child segment SEG4WY remains accessible from its logical 
parent SEG7 (note that SEG7 is not physically deleted). Also accessible 
ar2 segments SEG5 and SEG6, which are variable intersection data. The 
physical parent of the logical child (SEG3) is likewise accessible fron 
the logical child [SEG4&). 
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3. EXAMPLE OF DELETED SEGMENTS ACCESSIBILITY: A physically and 
logically deleted logical child can be accessed from its physical 
dependents. 

XXXXXXXXXKXXX XXXXXXXXXXXX XXXXXXXXXXXX 
X x SEG! x XPDx SEG3 x *x x SEG7T x 
x x PP x x xX PP x * Ky X LP x 
XXXXXXXXXXXX KXXXXXXXXXxXxX x * XXXXXXXXXXXX 
x x * * V : 
x x * * v 
XXXXXXXXEXXX XXXXXXXXXXXX* * VVVVVVVVVIVY 
X x SEG2 x xPDx SEGG x * v SEG8 v 
x x LC x* xLDx LC x Vv VLC v 
XXXXXXXXXXXX * XXXXXXXXXXXX VVVVVVVVVVVV 
* x 
* x 
* XXXXXXXXXXXX 
* xPDx SEGS x 
* x Xx x 
* XXXXXXXXXXXX 
* x 
* x 


* XXXXXXXKAUKXKX 
*xPDx SEG6 x 
x x LP x 
XXXXXXXXXXXX 


The above physical structures show that the logical child SEG4 is 
both physically and logically deleted. 


From a previous example (number 1) we know that SEG6 (a logical 
parent) is accessible from SEG2, if that segment (its logical child) is ) 
not physically deleted. Likewise we know that once we have accessed 
SEG6, its physical parents (SEG5, SEG4, SEG3) are accessable. It does 
not matter that the logical child is logically deleted (which is the 
only difference in this example from example 1). 


The third path cannot be blocked because a delete bit for this path 


does not exist. Thus the logical child SEG4& is accessible from its 
dependents regardless of its being physically and logically deleted. 
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4. EXAMPLE OF DELETED SEGMENTS ACCESSIBILITY: When a segment 
accessed by its THIRD path is deleted, it is physically deleted 
in its physical data base, but remains accessible from its THIRD 


path. 
ees CO eee __----__DATA_BASE CALLS 
XXXXXXXXXXXXX GHU "SEG5° STATUS=" BB! 
x SEG1 x DLET STATUS=' BE! 
XXX XXXXXXXXXX ee te gh a wa ee A ek ts ce oe 
x 
XXXXXXXXXXXXX ACTION: SEG5 is physically deleted 
x SEG2/SEG6 x by the action of the DLET call and 
XXXXXXXXXXXXKX SEG6 is physically deleted by prop- 
x agation. SEG2/SEG6 has unidirec- 
XXXXXXXXXXXXX tional pointers, so SEG2 was 
x SEG5 x considered logically deleted prior 
XXX XXXXXXXXKXX to the DLET call ('LD* bit only 
assumed set). 
XXXXXXXXXXXX KXXXXXXXXXXX XXXXXXXXXXXX 
Xx x SEG] x Xx x SEG3 xX *x x SEG7 x 
x x PP x x Xx PP x “ €x Xx LP x 
XXXXXXXXXXXX XXXXXXXXXXXX * © XXXXXKXXXXXKE 
x x x x V 
x x = x Vv 
XXXXXXXXKXXX XXXXXKXXXXXX* * VVVVVVVVVVVV 
Xx x SEG2 x x x SEGU x * V SEG8 Vv 
xLDx LC x* x Xx LC x Vv VLC v 
MXXXXXXXXKXXX * xXXXXXXXXXXXX VVVVVVVUVVVVV 
* x 
* > 4 
* XXXXXXXXXXXX 
* xPDx SEG5S x 
* x x x 
* XXXXXXXXXxXxXX 
* x 
* x 


 XMXXXXXXXXXX 
*x¥PDx SEG6 x 
x x LP x 
XXXXXXXXXKXXX 


The results are interesting. SEG5 is unaccessible when accessed by 
its physical parent path (from SEG4) unless SEG4& were accessed by its 
logical parent SEG7 (SEGS & SEG6 are accessible as variable intersection 
data). SEG5 is still accessible from its third path (from SEG6) because 
SEG6 is still accessible from its logical child. Thus a segment can be 
physically deleted by an application program and still be accessible to 
that application program, using the same PCB used to delete the segment. 
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5. ABNORMAL TERMINATION POSSIBILITY: If a logical parent is 
physically and logically deleted, it's DASD space will be 
released. For this to occur, all of its logical children must be 
physically and logically deleted. However, these logical ; 
children may not be DASD space released because of physical 
dependents with active logical relationships. Accessing such a 
logical child from its physical dependents may result in an 850 
through 859 abnormal termination if the LPCK is not stored in the 
logical child or if the concatenation definition is data 
sensitive to the logical parent. 


XXXXXXXXXXXX XXXXXXXXXXXX 
xXx x SEGI x XxPDx SEG3 xXx *x¥PDx SEG] x 
x x PP x x x PP x * *X¥LDX LP x 
xXXXXXXXXXXXXK XXXXXXXXXXXX x * 
x xX * fe 
x x * x 
XXXXXXXXXXXX XXXXXXXXXXXKX* * 
Xx x SEG2 xX xPDx SEG4 x * 
x «x LC x* xLDx Lc x 
XXXXXXXXXXxXx * XXXXXXXXXXKXX ‘ 
* x 
* x 
* XXXXXXXXKXXXX 
x XPDx SEG5 x 
* Xx x x 
* XX XXXXXXXXXKX 
* K 
m* x 


* XXXXX¥XXXXXXX 
*xy¥PDx SEG6 x 
x x LP x 


XXX XXXXXXXXX ) 


The logical parent SEG7 has been physically and logically deleted 
(the LD bit is never really set, but only assumed set. It is shown for 
the purpose of illustration). Alli of the logical children of the 
logical parent have also been physically and logically deleted. 
However, the logical parent has had its segment space released, whereas 
the logical child (SEG4) still exist due to an active logical 
relationship that préciudes releasing its space. 


If an application program accesses SEG4 from its dependents (SEG! to 
SEG2/SEG6 to SEG5S) IMS must build the logical parents concatenated key 
if that key is not stored in the logical child. When IMS/VS attempts to 
access the logical parent SEG7, the results will be an abnormal 
termination. The 850 through 859 abnormal termination codes indicate 
that IMS/VS followed a pointer that did not lead to the seqment 
expected. 
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AVOIDING ABNORMAL TERMINATION 


We must avoid creating a physically deleted logical child which can 
be accessed from below in the physical structure (its third path). A 
logical child can be accessed from below if any of its physical 
dependents are accessible through logical paths. 


First Solution 

One solution is to require the logical paths to dependents to be 
broken before physically deleting the logical child. This can be done 
by using a PHYSICAL rule for the dependents as long as no physical 
deletes are allow to propagate into the data base. Therefore no VIRTUAL 
rules on logical children can be allowed at or above THE LOGICAL CHILD, 
since with the ¥V rule a propagated logical delete causes a physical 
delete without a P rule violation check (see DETECTION OF PHYSICAL 
DELETE ROLE VIOLATION). The LOGICAL rule will also cause propagation if 
the PD bit is already, but the dependents PHYSICAL rule will prevent 
that case. Similarly, no VIRTUAL rule can be allowed on any logical 
parent above the logical child, since the logical delete condition would 
cause the physical delete. 


second Solution 

A second soiution is to break the logical path whenever the logical 
child is physically deleted. This can be accomplished for subordinate 
logical child segments with the VIRTUAL delete rule. Subordinate 
logical parent segments need to have bidirectional logical children with 
the VIRTUAL rule [must be able to reach the logical children) or 
physcially paired logical children with the VIRTUAL rule. This solution 
will not work with subordinate logical parent's pointed to by 
unidirectional logical children. 
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DETECTION OF PH 


YSICAL DELETE RULE VIOLATION 


The delete routine scans the physical structure containing the 
requested segment to be deleted to determine if any segment in the 
physical structure has the physical delete rule and whether that rule is 


violated. 
KXXXXXXXXXXXX 
x x SEG! x 
x x Xx 
XXXXXXXXXXXX 
x 
X RULE=L 
XXXXXXXXXXXX 
X xX SEG2 x 
x x LP x* 
XXXXXXXXXXRxX * 
Vv *x 
Vv x 
VVVVVVVVVVVV * 
Vv SEG3 v * 
Vv VLC v 
VVVVVVVVVVVV 
eenarn PCB 3 
XXXXXXXXXXX 
x xX SEGUY 
x x 
XXXXXXXXXXX 


xxXXXXXXXXXXX 
x x SEG4Y x 
x x LP x* 


xXXXXXXXXXXXX * 
x RULE=L *x * 


Xx te 
XXXXXXXXXXXX x * 
x x SEGS x * 
xX Xx LC x* 
XXXXXXXXXXXX 
x RULE=V 
ae x 
* xX XXXXXXXXXX 
* x xX SEG6 x 
* * x xX PP x RULE=any 
x * XXXXXXXXXXXX 
* * xX 
aK * x 


* * XXXXXXXXKXXX 
* *x x SEG7T x 

x x LC x RULE=P 
XXXXXXXXXXXX 


x 

x GHU "SEGUE 
x DLET 

x 


xXXXXXXXXXXX 

x x SEG8 x 

ey Xx LP x 

* XXXXXXXXXXXX 
RULE=L x 
x 

XXXXXXXXXXXX 

* x x SEGO x 

*y XxX LC x 

XXXXXXXXXXXX 

RULE=V 


STATUS=" pp 
STATUS=" DX? 


SEG7 (logical child of SEG3) has the physical delete ruie and it has 
lly deleted (the LD bit has not been set) so the physical 
rule is violated; a "DX" status code is returned to the application 


not been logica 


program and no 


segments are deleted. 
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PHYSICAL DELETE RULE TREATED AS LOGICAL 


- After the delete routine determines that neither the segment 

( specified in the DLET call nor any physical dependent of that segment in 
the physical structure has the physical delete rule, any physical rule 
encountered later (logical deletion propagated to logical child or 
logical parent causing physical deletion [(V rule) in another data base) 


is treated as LOGICAL. 


XXXXXXXXXXXX xXXXXXKXXXXXX XXXXXXXXXXXX 
x x SEG! x x x SEGU x xPDx SEGB x 
x xX x xX xX LP x* “xX xX LP x 
XXXXXXXXXXXX XXX¥XXXERKXXXX * * XXXXXXXXXXXX 
x x RULE=L x -* RULE=L x 
x ROULE=L x * x 
XXXXXXXXXXXX XXXXXXXXXNXXX x * XXXXXXXXXXXX 
x x SEG2 x xPDx SEG5 x * * xPDx SEGY x 
x xX LP x* xLDx LC x* *xLDx LC x 
MXXXXXXXXXXX * XXXXXXXXXXXX XXXXKXXXXXXXX 
Vv * * x RULE=V RULE=V 
Vv * x 
vvvvvvvvvvvV * = * MXXXXXXXXK XX 
Vv SEG3 v * * xPDx SEG6 x 
Vv VLC v = * K Xx PP x RULE=any 
VVVVVVVVVVVY *x* * XXXXXXXXXXXX 
me a xX 
x x xX 
* © XKXXXXXXXXXXX 
* *xXPDx SEG7 x 
x x LC x RULE=P 
MXXKXKXXXXXX 
es PGB, ee DATABASE CALLUS 002 ci 
XXXXXXXXXXXX 
x x SEG8 x GHU "SEGB? STATUS=' bp’ 
x x x DLET STATUS=" pw! 
xxXXXXXXXXXKXX 


SEG8 and SEGI are both physically deleted, and SEG9 is logically 
deleted (V rule). SEG5 is physically and logically deleted because it 
is the physical pair to SEG9 (with physical pairing setting the LD bit 
in one set the PD bit in the other and vice verse). Physically deleting 
SEG5 causes propagation of the physical delete to SEG5S's physical 
dependents, thus SEG6 and SEG7 are physically deleted. Notice that the 
physical delete of SEG7 is prevented if the physical deletion had 
started by issuing a DLET call for SEGU. But the physical rule of SEG7 
is treated as logical in this case. 


INSERTING PHYSICALLY AND/OR LOGICALLY DELETED SEGMENTS 

When a segment is inserted, a replace operation will be performed 
(that is, space will be reused) and existing dependents of that segment 
remain, provided: 

e The segment to be inserted already exists (same segment type and 
same key field value for both the physical and logical sequencing), 
and 

e The delete bit is set on for that segment along the path of 


insertion. 
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If the DB organization is HD, the logical twin chain will be 
established as required, and existing dependents of that segment will 
remain. 


If the DB organization is HISAM, and the root segment is physically 
and logically deleted before the insert is attempted, then the first 
LRECL for that root in primary and secondary DSGs is reused and 
remaining LRECLS on any OSAM chain are dropped. 


DELETE RULES SUMMARY 


The DLET Call 


A DLET call issued against a concatenated segqment (SOURCE=DATA/DATA, 
DATA/KEY, KEY/DATA) is a DLET call against the logical child only. 


A DLET call against a logical child which has been accessed from its 
logical parent is a request that the logical child be logically deleted. 


In all other cases a DLET call issued against a segment is a request 
for that segment to be physically deleted. 


Physical Deletion 


A physically deleted segment cannot be accessed from its physical 
path with one exception -- if one of the physical parents of the 
physically deleted segment is a logical child segment which can be 
accessed from its logical parent, then the physically deleted segment is 
accessible from that logical child since the physical dependents of a 
logical child are “variable intersection data." 


Logical Deletion 


By definition, a logically deleted logical child cannot be accessed 
from its logical parent. Unidirectional logical child segments are 
assumed to be logically deleted. 


By definition, a logical parent is considered logically deleted when 
physical deletion has occured for all of its logical children and for 
all of its physical children which are part of a physically paired set. 


Access Paths 


Neither physical nor logical deletion of a segment prevents access to 
the segment from its physical or logical children, or from the segment 
to its physical or logical parents. A physically deleted root segment 
can be accessed only from its physical or logical children. 


Propagation of Delete 
In bidirectional physical pairing, physical deletion of one of the 
pair of logical children causes logical deletion of its pair. Likewise, 

logical deletion of one causes physical deletion of the other. 


Physical deletion of a segment propagates logical deletion requests 
to its bidirectional logical children and propagates physical deletion 
requests to its physical children and to any index pointer segments for 
vhich it is the source segment. 
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DELETE RULES 


Further delete operations are governed by the following delete rules: 


1. PHYSICAL: If the segment is not already logically deleted, then 
a DLET call against the segment or any of its physical parents 
results in a 'DX' status code and no segments are deleted. If a 
request is made against the segment as a result of propagation 
across a logical relationship, then the rule acts like the 


LOGICAL rule. 


2. LOGICAL: Either physical or logical deletion can occur first and 


neither causes the other. 


3. VIRTUAL: Either physical or logical deletion can occur first. 


If the segment becomes loyically deleted as the result of a DLET 
call, then it will he physically deleted also. 


Physical Parent of a Virtually Paired Logical Child 
1. PHYSICAL/LOGICAL/VIRIUAL: Meaningless. 


2. BIDIRECTIONAL VIRTUAL: Whenever all physical children which are 
virtually paired “logical children are logically deleted, the 
physical parent segment is physically deleted. 


Logical Child 


1. PHYSICAL: If the segment is not already logically deleted, then 
a DLET call requesting physical deletion of the segment or any of 
its physical parents results in a 'DX* status code and no 
segments are deleted. If a delete request is made against the 
segment as a result of propagation across a logical relationship, 
or if the segment is one of a physically paired set, then the 
rule acts like the LOGICAL rule. 


2. LOGICAL: Either physical or logical deletion can occur first and 
neither causes the other. 


3. VIRTUAL: Either physical or logical deletion can occur first and 
either causes the other. If this rule is used on only one 
segment of a phySically paired set, it acts like the LOGICAL 


rule. 


Depending on the data base organization, DASD space may or may not be 
reused when it is released. DASD space for a segment is released when 
the following conditions are met: 

* Space has been released for all physical dependents of the segment. 
e The segment is physically deleted. 


e If the segment is a logical child or a logical parent, then it must 
be physically and logically deleted. 
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e If the segment is a dependent of a logical child (variable 
intersection data) and the DLET call was issued against a physical 
parent of the logical chiid, then the logical child must be both 
physically and logically deleted. ) 


e If the segment is a primary index pointer segment, the space must 
have been released for its target segment. 


DEFINING A LOGICAL DATA BASE 


To identify which segment types in one or more physical data bases 
are used in a logical data base, the segment types in the physical data 
bases are redefined in a logical data base through DBDGEN using SEGM 
statements. The NAME= operand of the SEGM statement is used to specify 
the name used for the segment type in the logical data base, and the 
SOURCE= operand is used to identify which segment type or types in 
physical data bases are represented by the name specified in the logical 
data base. On the SOURCE= operand, the user specifies the name of the 
segment type in a physical data base that is represented in the logical 
data base through the name specified on the NAME= operand. Also 
Specified on the SOURCE= operand is the name of the physical data hbase 
that contains the segment type being defined in a logical data base. 
When defining a concatenated segment type in a logical data base, the 
names of both segment types that comprise the concatenated segment type, 
and the name of the physical data base that contains each segment type 
to be concatenated are specified on the SOURCE= operand. 


As in the definition of a physical data base, the hierarchy of 
segment types in a logical data base is defined through use of the 
PARENT= operand of the SEGM statement, and through the order in which 
SEGM statements ar2 presented as input to DBDGEN. The PARENT= operand 
is used to specify the physical parent segment type of each dependent 
segment type defined in the logical data base, and the order in which 3 
SEGM statements are arranged determines the left to right order of 
physical child segment types of each physical parent segment type. 


A concatenated segment type is defined in a logical data base to 
enable use of a logical relationship. When a concatenated segment type 
is defined in a logical data base, the concatenated segment type enables 
access to the destination parent in the logical relationship. In 
addition, subject to rules for defining logical data bases, the 
concatenated segment type enables crossing a logical relationship to 
access segments that are in the hierarchic path of the destination 
parent in the physical data base of the destination parent. 


Before the rules for defining logical data bases can be understood, 
crossing a logical relationship, and the first and additional logical 
relationships crossed in a hierarchic path of a logical data hbase must 
be understood. 


Definition of Crossing a Logical Relationship 


A logical relationship is considered crossed when it is used ina 
logical data base to access a segment that is a physical parent or a 
physical dependent of a destination parent in the destination parents 
physical data base. If a logical relationship is used in a logical data 
base to access a destination parent only, the logical relationship is 
considered not to be crossed. In Figure 4-34, DBD! and DBD2 are two 
physical data bases with a logical relationship defined hetween then. 
DBD3 through DBD6 are the four logical data bases that can be defined as 
a result of the logical relationship between DBD? and DBD2. If the | 
structure shown for DBD3 is defined as a logical data base, no logical ) 
relationships are crossed since no physical parent or physical dependent 


4.104 IMS/VS System/Application Design Guide 


of a destination parent is included in the logical data base. If DBD4 
through DBD6 were defined as logical data bases, a logical relationship 
is crossed in each case since each logical data base contains a physical 
parent or a physical dependent of the destination parent. 


Physical Data Bases 





Logical Data Bases 





No crossing 





A logical relationship is crossed 


Figure 4-34, Definition of Crossing a Logical Relationship 


Multiple logical relationships can be crossed ina hierarchic path of 
a logical data base. Figure 4-35 shows three physical data bases (DBDI, 
DBD2 and DBD3) in which logical relationships have been defined. Also 
in the figure are two logical data bases (DBD4 and DBD5) that can be 
defined as a result of the logical relationships defined in the physical 
data bases. In DBD4, the two concatenated segment types (BF and DI) 
that have been defined enable access to all segment types in the 
hierarchic paths of their respective destination parents. If either 
logical relationship or both are crossed, each is considered to be the 
first logical relationship crossed in the hierarchic path of logical 
data base DBD4 since each concatenated segment type is reached by 
following the physical hierarchy of segment types in DBD1!1. In logical 
data base DBD5, an additional concatenated segment type (GI) has been 
defined that was not included in DBD4Y. The additional concatenated 
segment type GI in DS3SD5 enables access to segments in the hierarchic 
path of the destination parent if crossed. When the logical 
relationship enabled by the concatenated segment GI is crossed, this 
constitutes an additional logical relationship crossed in the hierarchic 
path of the logical data base since, from the root of the logical data 
base, the logical relationship enabled by the concatenated segment type 
BF must be crossed to enable access to the concatenated segment type GI. 
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Physical Data Bases 





Logical Data Bases 





Figure 4-35. The First Logical Relationship Crossed in a Hierarchic 
Path of a Logical Data Base 


When the first logical relationship is crossed in a hierarchic path 
of a logical data base, access to all segment types in the hierarchic 
path of the destination parent is enabled as follows: 


e Parent segment types of the destination parent are included in the 
logical data base as dependents of the destination parent in reverse 
order as shown in Figure 4-36. 


e Dependent segment types of the destination parent are included in 


the logical data base as dependents of the destination parent 
without change in their order as shown in Figure 4-36. 
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Hierarchic path Resulting order in 
of physical data the hierarchic 
path of a logical data base 






Destination 
parent 





Figure 4-36. Logical Data Base Hierarchy Enabled by Crossing the First 
Logical Relationship 


When an additional logical relationship is crossed in a hierarchic 
path of a logical data base, access to all segments in the hierarchic 
path of the destination parent is enabled as in the first crossing. 


Rules for Defining Logical Data Bases 
1. The root segment type of a logical data base must be the root 
segment type of a physical data base. 


2. A logical data base must be supported by one or more physical 
data bases. A logical data base must use only those segment 
types, and physical and/or logical relationship paths that are 
defined in the physical DBD generation(s) referenced by the 
logical DBD generation. 


3. The path used to connect two segments in a logical data base 
{that is, a parent and a child) must have been defined as a 
physical relationship path or a logical relationship path in the 
physical DBD generation(s) referenced by the logical DSD 
generation. 


4. Physical relationship paths and logical relaticnship paths may be 
intermixed in a hierarchical segment path of a lagical data base. 


5. After a logical relationship has been crossed in a hierarchic 
path of a logical data base, additional physical relationship 
paths and/or iogical relationship paths may be included by 
proceeding in an upward and/or downward direction from the 
destination parent. When proceeding downwards along a physical 
relationship path from the destination parent, direction may not 
be changed except by crossing a logical relationship. When 
proceeding upwards along a physical relationship path from the 
destination parent, direction may be changed. 


6. Dependents in a logical data base must appear in the same 


relative order as they appear under their parent in their 
physical data base. If a segment in a logical data base is a 
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concatenated segment (that is, a logical child concatenated with 

either its physical or logical parent), the physical children of 

each of the concatenated segments may not be intermixed. The ' 
relative order of the children of each of the concatenated ) 
segments must remain unchanged. 


7. Different variations of a concatenated segment type can be 
defined as physical child segment types of a physical parent 
segment type, but only one variation can have dependent segment 
types. Figure 4-37 shows the four variations of a concatenated 
segment type that can be defined in a logical data base. When 
multiple variations are defined under a single physical parent 
segment type. the variation of the concatenated segment type 
under the physical parent that has dependents must be the left 
most variation of the concatenated segment type. A PCB for the 
logical data base can be-sensitive to only one variation of the 
concatenated segment type. 


Physical Parent 
Segment Type 






Key: 
LC—Logical child segment type 
DP-— Destination parent segment type 
K—KEY sensitivity specified for the segment type 
D—DATA sensitivity specified for the segment type ) 


Figure 4-37. Variations of a Concatenated Segment Type Enabled by 
Specification of KEY and DATA Sensitivity 


When only one logical relationship is crossed in a hierarchic segment 
path of a logical data base to reach a destination parent: 


ae All segment types on which the destination parent is dependent in 
its physical data base can be included in the logical data base 
as dependents of the destination parent in inverted order. 


b. All segment types that are dependent on the destination parent in 
its physical data base can be included in the logical data base 
as dependents of the destination parent without change in their 
order. 


c. All segment types that are dependent on any of the inverted order 


segment types defined in (a) can be included without change in 
their order. 
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Physical Data Base Logical Data Base can include 


LOGICAL 
CHILD 
pe dtc die 


(DESTINATION 
LOGICAL PARENT) 
CHILD ‘ 


# | poe | * | pe a # | 


Example 1. 


Secondary indexes are used to establish alternate entries to physical 


or logical data bases for application programs. Following are 
definitions of the terms used for secondary indexing: 


Secondary Index 

A secondary index is comprised of an index pointer segment type 
defined in a secondary index data base that provides an alternate 
entry into a physical or logical data base. 

Index Pointer Segment Type 

A segment type defined in a secondary index data base that contains 
the data and pointers used to index an "index target segment typa" 
in a physical or logical data base (see Figure 4-38). 

Index Target Segment Type 


A segment type defined in a physical or logical data hbase that is 
pointed to by an index pointer segment type {see Figure 4-38). 


Index Source Segment Type 


A segment type that is the source from which a secondary index is 
created (see Figure 4-38). 


Secondary Processing Sequence 


The sequential order in which occurrences of an index target segment 
type are accessed through a secondary index. 
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e Secondary Data Structure 


The hierarchic order of segment types in a physical or logical data 
base that results automatically when a data base is accessed through 
a secondary index. 


SECONDARY 
PHYSICAL OR LOGICAL DATA BASE INDEX DATA BASE 





Can be root 
or dependent 
segment type. 












INDEX 
TARGET 
SEGMENT TYPE 


INDEX 
POINTER 
SEGMENT TYPE 








Can be the 
same segment 
type as index 
target segment 
type, or as 
shown, a dep- 
endent of the 
index target 
segment type. 















INDEX SOURCE 
SEGMENT TYPE 


The content of a specified 

field or fields in each index 
source segment is duplic- 

ated in the respective index 
pointer segment generated 

from each index source segment. 


Figure 4-38. Segment Types Associated with a Secondary Index 


An index target segment type can be the root or a dependent of a 
physical or logical data base, and an index source segment type can be 
either the index target segment type itself or any physical dependent of 
the index target segment type. A secondary index contains one index 
pointer segment for each occurrence of the index source seqment type in 
a physical or logical data base. If the same segment type in a data 
base is used as both the index target and index source segment types, 
the secondary index contains one index pointer segment that points to 
each index target segment. If a dependent of an index target segment 
type is used as the source segment type for a secondary index, the 
secondary index contains one index pointer segment that points to an 
index target segment for each source segment that is a dependent of that 
index target segment as shown in Figure 4-39. 


The user specifies through DBDGEN what data within the index source 
segment type is to be used to index occurrences of the index target 
segment type. From one to five fields, that can be non-contiguous, 
within the index source segment type can be specified for use as search 
data in a sacondary index. When specified, the content of each field 
specified is copied in the search field of the respective index pointer 
segment generated from each source segment. 
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SECONDARY PROCESSING SEQUENCE 


Entry to a data base through a secondary index enables access to the 
index target segment type and all segment types in the hierarchic path 
of the index target segment type. Through the secondary index, the 
order in which index target segments are accessed is called their 
secondary processing sequence. The secondary processing sequence of 


index target segments is determined by the search field values placed in 
index pointer segments. 


INDEXED DATA BASE INDEX DATA BASE 


CITY 


NAME is index target | 
segment type | 


NAME 
ADAMS 
NAME 
| JONES BLACK BLUE YELLOW 
| 
| NAME 
| SMITH 
Index Source : 
segments 
BLUE 
YELLOW 


Unless suppressed, one index pointer 
/ segment is generated from each index 


/ source segment. 
Automobile Segment Type used as 
source for secondary index “ 





MODEL COLOR WEIGHT 





TT 
used as 
search field 
for secondary 
index 


Figure 4-39. Indexing to NAME Segments Based on the Color Field of a 
Dependent 


SECONDARY DATA STRUCTURE 


The order in which segment types in the hierarchic path of an index 
target segment type are accessed is called their secondary data 
structure. The hierarchic arrangement of segment types for the 
secondary data structure is created automatically by IMS/VS. To enable 
use of the secondary data structure, the user must define sensitivity to 
the segment types in the secondary data structure through PSBGEN. 


Figure 4-40 shows a physical data base hierarchy in which a dependent 
segment type is indexed through a secondary index. Also shown is the 


secondary data structure for the segment types in the hierarchic path of 
the index target segment type. 
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PHYSICAL DATA BASE HIERARCHY 


cs . 
ia 
ITE] 


*INDEX ON SEGMENT TYPE G 


oe lf Jie 


SECONDARY DATA 
STRUCTURE HIERARCHY 


EE] 2 
a 


Figure 4-40. Secondary Data Structure 


The secondary data structure for segment types in a data hase is 
determined as follows: 


1. The index target segment type is the root. 


2. Parent segment types of the index target segment type ina data 
base become the left most dependents of the index target segment 
type in reverse order. 


3. All dependents of the index target segment type are included in 
the secondary data structure without change in their order except 
when a parent of the index target segment type is included in the 
secondary data structure as stated in item 2. In this case, 
dependents of the index target segment type are displaced one 
position to the right in the secondary data structure. 


4. Only those segment types in the hierarchic path of the index 
target segment typ2 are included in the secondary data structure. ) 
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5. 


When the root segment type of a data base is indexed through a 
secondary index, the hierarchy of the data base is unchanged for 
the secondary data structure. 


Options and Rules for Secondary Indexing 


e A secondary index can be defined for any HDAM or HIDAM data base. 


e A secondary index can be defined for any single data set group HISAMS 
data base. 


e A secondary index cannot be defined for a multiple data set group 
HISAM data base. 


e A secondary index cannot be defined for a HSAM data base. 


A secondary index can be defined using: 


e Fields in the index source segment type that contain unique or 
non-unique data for the search field of the secondary index. 


e Up to 5 non-contiguous fields in the index source segment type as 
the search field of a secondary index. 


To enable processing a secondary index as a data base itself: 


e The user can specify that data in fields of index source segments is 
to be duplicated in the index pointer segment generated from each 
index source segment. 


e Index pointer segments can contain any additional user data desired. 


A secondary index can be used: 


e To index selectively or sparsely by using an option and/or exit 
provided to enable suppressing the creation of index entries for 
desired index source segments. 


e To access segment types in a single hierarchic path of a data hbase 
uSing the index target segment type as the root for all segment 
types in that path. 


® To selectively access a given segment, through data contained in 
that segment or a dependent of that segment. 


e To access a given dependent in an HDAM or HIDAM data base in less 
time than is normally required through the primary addressing 
method. 


Following are the rules that must be observed in secondary indexing: 


1. 


2e 


In a physical data base, a logical child, or a dependent of a 
logical child cannot be an index target segment type. 


You cannot declare a secondary processing sequence on an index if 
the target is a concatenated segment type or a dependent of a 
concatenated segment type in a logical data base. 


When using a secondary processing sequence, you cannot insert or 
delete an index target segment, or any segment on which an index 
target segment is dependent in a physical data base. 

Data in any fields of segments can be changed except for data in 
sequence fields. If data in fields of an index source segment is 
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changed and those fields are used in the search or subsequence 

fields of an index pointer segment, the index pointer segment is 

deleted from the position determined by its old key, and 

reinserted into the position determined by its new key. ) 


5. If a variable length segment type is used as an index source 
segment and an attempt is made to insert an occurrence of the 
segment type whose length does not include any fields or portions 
of any fields specified for use in the search, subsequence or 
duplicate data fields of an index pointer segment, one of the 
following actions occur: 


ae If the missing index source segment data is used in the 
search field of an index pointer segment, generation of the 
index pointer segment for that source segment is suppr2ssed. 


b. If the missing index source segment data is used in the 
subseguence or duplicate data fields of an index pointer 
segment, the index pointer segment field will contain one of 
the three following representations of zero for the missing 
data [P="000F", x=xX'O0O", or C="0'). The representation used 
will be the type specified on the FIELD statement that 
defined that index source segment field. 


6. When symbolic pointing only is used to point to index target 
segments from index pointer segments, unique sequence fields must 
be defined in the index target segment type and all segment types 
on which the index target segment type is dependent in it's 
physical data base. 


7. DL/I does not assume responsibility for the order of index 
pointer segments that contain non-unique keys after a 
reorganization of the secondary index. 


8. <A logical child segment type cannot be used as an index source 2 
segment type. However, a dependent of a logical child can be 
used as an index source segment type. 


9. In a logical data base, no qualification on indexed fields is 
allowed in the SSA for a concatenated segment. However, an SSA 
for any dependent of a concatenated segment can be qualified on 
an indexed field. 


10. The insert rule of FIRST is always followed when entries are 
added to secondary indexes for data base naintenance. 


thus 


Organization of Secondary Indexes in Auxiliary Storage 


= —_—/! - as a ap a 


A secondary index is stored using a VSAM key sequenced data set only 
if index pointer segment keys are all unique. If not unique, the index 
is stored in a key sequenced and an entry sequenced data set pair. The 
key sequenced data set is used to store the first occurrence of an index 
pointer segment with a given key, and the entry sequenced data set is 
used to store additional index pointer segments that contain the same 
key. Within both data sets, one logical record is used to store each 
index pointer segment. When multiple index pointer segments with the 
same key are stored in the secondary index data base, a pointer is 
placed at the beginning of the logical record that contains each to 
chain them together. In the chain, the key sequenced data set logical 
record always contains the first index segment with a given key, and it 
~oints to one of the duplicates in the entry sequenced data set. fhe 
sequence in which logical records that contain duplicates are chained in 
the entry sequenced data set is determined by the insert rule of FIRST. ) 
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Index Pointer Seqment Format 


Figure 4-41 shows the structure of an index pointer segment within a 
VSAM logical record. In a logical record, the optional non-unique 
pointer is used to chain logical records that contain index pointer 
segments with duplicate keys. The remaining portion of each logical 
record contains an index pointer segment. 


VSAM logical record 
——— PREFIX San lon A DATA 


Pointer to an 


ridex Direct 


‘ address Subsequence Duplicate Concatenated 
Adan! Delete index Constant field data field | key of index 


Segment 
witha 
non-unique 
key * 


flag target (Optional) (Optional) (Optional) | target segment 
segment ean ; 
pointer** 





* Not present if a unique sequence field is defined in the index pointer segment type. 
**Not present when symbolic pointing to the index target segment type is specified 


*** Present when symbolic pointing to the index target segment type is specified, and the 
concatenated key is not present in the subsequence or duplicate data fields. 


Figure 4-41. VSAM Logical Record and Index Pointer Segment Formats 


An index pointer segment is a fixed length segment that contains a 
prefix and a data portion. The prefix contains a one byte delete flag 
and a four byte pointer field when the index uses direct address 
pointers to point to an index target segment. If symbolic pointing is 
designated in the index data base, the pointer field is omitted from the 
prefix. The delete flag is used to mark an index pointer segment as 
being deleted when the respective index source segment from which an 
index pointer segment was created is deleted. For HDAM and HIDAM data 
bases, the pointer field contains a direct address pointer that is used 
in secondary indexes to point to the occurrence of the index target 
segment type that is indexed by an index pointer segment. Symbolic 
pointers may also be specified for HDAM and HIDAM data bases if the user 
desires. In a secondary index for a HISAM data base, the concatenated 
key of the index target segment must be stored in the data portion of 
the index pointer segment to point to the index target segment. The 
user can specify its position within the data portion by defining the 
concatenated key as a system related field. When not defined as a 
system related field, IMS/VS automatically places the concatenated key 
in a predetermined position in the index pointer segment as shown in 
Figure 4-41. 


The data portion of an index pointer segment contains up to four 
classes of system maintained datas: constant, search, subsequence, and 
duplicate data. Of the four, only search data is required for index 
pointer segments. Constant, subseguence, and duplicate data are 
optional. 


Three fields and a constant can be defined in an index pointer 
segment type through an XDFLD statement. The fields defined through an 
XDFLD statement are called search, subsequence and duplicate data 
[DDATA) fields. A search, subsequence or duplicate data field in an 
index pointer segment type is comprised of one to five fields that are 
defined in the index source segment type through FIELD statements. For 
each respective field in the index pointer segment type, a list of names 
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of one to five fields defined in the index source segment type can be 
specified for use as that index pointer segment field. The content of 
the index source segment fields specified are duplicated in the 
respective index pointer segment field when each index pointer seqment 
is created. The sequence of field names in a list determines the order 
in which the fields are stored in the index pointer segment field. 
Names of source segment fields can be specified in any desired order. 


In auxiliary storage, the key of an index pointer segment consists of 
the values in the constant, search field, and subsequence field when all 
three are specified on an XDFLD statement. Of the three, only the 
search field is required in each index pointer segment. The constant 
and subsequence field are optional. When only the search field is 
specified for an index pointer segment type, the search field contains 
the entire key of each index pointer segment. When a constant is 
specified, the key of an index pointer segment consists of the constant 
followed by the search field value. When a subsequence field is 
specified, the subsequeace field value is appended to the search field 
value and it becomes a part of the key of the index pointer segment. 

The combined length of the constant, search and subsequence fields that 
make up a key must not exceed 240 bytes. 


The use of each field in an index pointer segment is as follows. 


Constant 


When specified, a one byte constant occupies the first byte of the 
data portion of each occurrence of the index pointer segment type. The 
constant is used to identify all index pointer segments associated with 
each secondary index when multiple secondary indexes are defined in the 
Same index data base. The use of the shared index option is described 
under the heading of "Shared Index Data Bases." 


Search Field 


The data in the search field of an index pointer segment is a 
collection of the data in from one to five index source segment fields. 
In an index pointer segment, the search field is used as all or a part 
of the key of that index segment. The search field contains the 
value(s) in a field or fields of an index source segment on which an 
index target segment is indexed. This means to the user, the presence 
of the constant and/or subsequence fields in the keys of index pointer 
segments are transparent to calls. To process a specific index target 
segment through a secondary index, the SSA of a call is qualified on the 
search field value only. 


Subsequence Field 


The data in the subsequence field of an index pointer segment is a 
collection of the data in from one to five index source segment fields. 
The purpose of the subsequence field is to extend the key of index 
segments to prevent storing index segments in an overflow data set in 
cases where search field values are non-unique. Index segments in an 
overflow data set can degrade performance. One example could be that of 
indexing a personnel data base segment type by birth data. If the last 
name of the individual were specified as subsequence data then all 
segments with identical birth date fields would be stored in 
alphabetical order by last name in the primary storage data set. This 
would not necessarily eliminate all synonyms, but most keys would now be 
unigue. The extension of the index pointer segment key by adding the 
subsequence field is transparent to the caller since calls are qualified 
on search field values only. 
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When the key of an index pointer segment type is comprised of search 
field values only, index pointer segments with the same search field 
value are stored in one key sequenced data set logical record, plus the 
required number of entry sequenced data set logical records. By 
specifying a subsequence field, the key of index pointer segments is 
extended. When subsequence field values are unique, multiple 
occurrences of the index pointer segment type with the same search field 
value are stored in consecutive logical records in the key sequenced 
data set. Increased performance results since no searches among the 
duplicates in the entry sequenced data set are required. 


Duplicate Data Field (DDATA) 


Data in the DDATA field of an index pointer segment is a collection 
of the data in one to five index source segment fields. When specified, 
space for its contents is alloted adjacent to the subsequence or search 
field value in an index pointer segment. The DDATA field is defined to 
prompt the system to duplicate data contained in index source segments 
in index pointer segments to enable using that data when a secondary 
index is processed as a data base itself. 


Additional Data in Index Pointer Segments 


The user can include any additional data desired in index pointer 
segments by specifying a length for the index pointer segment type that 
is sufficient to include the additional data. When included, the 
additional data is available to the user when processing the secondary 
index as a data base itself. The user should note however, that initial 
loading of additional data, and maintenance of the additional data when 
reorganizing an indexed data base maintenance is his responsibility. 
During reorganization of an indexed data base, the secondary index (s) 
for that data hase are recreated. When each secondary index is 
recreated, any additional user data that existed in the original 
secondary index is lost. 


System related fields are defined in index source segment types for 
use in secondary indexing. They are defined using FIELD statements, and 
can only be defined for index source segment types. Two types of system 
related fields can be defined for use in secondary indexing. 


The first type of system related Field consists of defining a portion 
Or all of the concatenated key of an index source segment as a field 
within the index source segment. The name of this field can be up to 
eight characters long, and its name must begin with the three characters 
7ZCK. It may appear in the field list for either subsequence or DDATA 
fields defined by the XDFLD statement. 


The name of the second type of system related field begins with the 
three characters /SX. A /SX field is a four byte field that contains an 
IMS/VS generated value that uniquely identifies a source segment. It 
may appear only in the subsequence field of an index pointer segment, 
and may only appear if the index source segment is in an HDAM or HIDAM 
data base. 


System related fields are defined in the index source segment type, 
but do not physically exist as fields within that segment type. System 
related fields are defined in the source segment type for use in the 
subsequence or DDATA fields of index pointer segments. The subsequence 
and DDATA fields of the index pointer segment type are defined ¢hrough 
an XDFLD statement. In defining each, the names of up to five fields 


Data Base Design Considerations 4.117 


defined in the index source segment type can be specified for each on 
the XDFLD statement. 


The /CK or /SX fields are used in the subsequence field of index ) 
pointer segments to make their keys more unique. In addition, a /CK 
field can be used to store portions of the concatenated keys of 
occurrences of the index source segment type in their respective index 
pointer segments. This may reduce space requirements where pointing is 
symbolic and part of the concatenated key is to be used as subsequence 
data. In a secondary index for a HISAM data base, the concatenated key 
of each index target segment must be included in its" respective index 
pointer segment for use as a symbolic pointer. When not included in the 
subsequence or DDATA fields of the index pointer segment type used for a 
HISAM data base, IMS/VS automatically appends the concatenated key of 
each index target segment to any data in the subsequence or DDATA fields 
of the respective index pointer segment. 


Two operands, that can be specified during DBDGEN, can be used to 
suppress the creation of index pointer segments. The two are the 
NULLVAL=, and the EXTRTN= operands on the XDFLD statement. 


In the NULLVAL= operand, a one byte self-defining term, or the words 
BLANK or ZERO can be specified. If the NULLVAL operand is specified, 
all fields in an index source segment that comprise the search field in 
the index pointer segment are checked to see if each byte within the 
field(s) contains the specified vaiue. When the field or fields in the 
index source segment are filled with the specified character, an index 
pointer segment is not created. 


The EXTRTN= operand is used to specify the name of an index , 
Maintenance exit routine that is supplied by the user to suppress the j 
creation of selected index entries. 


Index Maintenance Exit Routine 


Secondary indexing allows specification of a user supplied index 
maintenance exit routine which can selectively suppress the creation of 
index segments. The routine enables the user to control the density of 
a secondary index. One exit routine is allowed for every secondary 
index or a generalized routine may be written to serve several indexes. 
For detailed information on index exit maintenance routines, see the 


The name given to the load module used for controlling index 
maintenance must be the value of the EXTRTN= operand on the XDFLD 
statement in the DBD generation for the indexed data hbase. 


When an index source segment is inserted, deleted, or replaced in a 
data base, DL/I index maintenance keeps the index synchronized with the 
contents of the data base. The action taken depends on the operation 
being performed: insert, delete, or replace. 


When a source segment is inserted, a copy of the proposed indexing 
seqment is constructed during index maintenance. The NULLVAL test and 
exit routine test are performed on the copy to determine the suppression 
status of the indexing segment. If no suppression status is indicated, 
the indexing segment is inserted into the index. ) 
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When a source segment is deleted, a copy of the alleged existing 
indexing segment is constructed during index maintenance. The NULLVAL 
and exit routine tests are performed to determine the suppression status 
of the indexing segment. If no suppression status is indicated, the 
matching segment is found in the index and deleted. 


If suppression status is indicated for an insert or delete, no 
further processing is required for that entry. 


When a source segment is replaced, an index entry may or may not be 
affected. The indexing segment may be replaced or it may be deleted and 
a new indexing segment inserted. It is also possible that no action is 
required. The action taken is determined by comparing the constructed 
copies of the old and new indexing segments. The following describes 
the action to be taken: 


e If no suppression is indicated for either segment and: 
- there is no change to indexing’ segment, no action is taken. 


- only the data in the indexing segment is changed, the indexing 
segment is replaced. 
® 
- the key in the indexing segment is changed, the old segment is 
deleted and a new segment is inserted. 


e If suppression is indicated :; 


- for the old indexing segment but not the new, the new indexing 
segment is inserted. 


~ for the new indexing segment but not the old, the old indexing 
ségment is deleted. 


- for both the old and new indexing segment, no action is taken. 


The question asked by the DL/I index maintenance routine when it 
invokes the user index exit routine is, "Will this index pointer segment 
appear in the index?" The exit routine answers the question through a 
return code. 


Suppression of indexing by the exit routine must be consistent. The 
Same index pointer segment cannot be examined at two different times and 
have suppression indicated only once. Also, user data cannot be used to 
evaluate suppression, Since the actual index pointer segment is only 
seen by the exit routine just before insertion of the new one. In the 
cases of replace and delete, only a prototype is passed which contains 
the constant, search data, subsequence data, and source data, plus any 
symbolic pointer which may have been added. 


Multiple secondary indexes can be placed in a single shared index 
data base. A shared index data base is created, accessed, and 
maintained in the same manner as a data base containing only one 
secondary index. To be eligible for combining, all indexes must be 
comprised of segments of equal length, with key fields of equal length, 
and with equal key offset positions. A maximum of 16 indexes can share 
a single shared index data base. Each secondary index in a shared index 
data base must have a constant specified which uniquely identifies that 
index. The advantage of a shared index data base is a reduction in the 
number of control blocks for VSAM and DL/I. 
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A secondary index can be processed as a data base by providing a PCB 
which references the DBD of the secondary index. The purpose of 
processing a secondary index as a data base could be to scan the 
subsequence or duplicate data fields, to perform logical comparisons or 
data reduction between two or more indexes, or to add to or change the 
user maintained data area. Whatever the purpose of processing a 
secondary index separately, the following guidelines and restrictions 
apply: 


e No changes to system-maintained data fields in the index pointer 
segment will be aliowed unless ACCESS=(,,NOPROT) is specified in the 
index DBD. Attempts to change system maintained data without the 
NOPROT option specified will result in an AM status code. 

e Inserts will not be permitted to any data base in which ACCESS=INDEFX 
is specified 


e Any changes to system-maintained data in an index may render the 
index as unuseable and unmaintainable. 


® Deletion of index entries by the user when the associated index 
source segments exist will result in NE status codes if the user 
makes updates to the index source segment which will result in index 
maintenance. @ 


e Qualification on the key of index pointer segments in SSA's must 
supply a value which includes not only the search portion of the 
key, but also the constant and subsequence data if supplied. fThis 
is the only case in secondary indexing that the user is aware of the 
constant and subsequence data in the key. 


e In processing a secondary index which is a member of a shared index 
data base, the secondary index is regarded as a separate index data 
base. A series of GN calls will not violate the boundaries of the 
secondary index for which they are intended. Each secondary index 
in the shared index data base has its unique DBD name and root 
segment name. 


Secondary Indexes and Seqment Search Arguments 


SSAs of calls for index target segments can be qualified on the 
search field of one or more secondary indexes when accessing index 
target segments through their primary or secondary processing sequence. 
This is accomplished by using indexed fields defined within the index 
target segment type to qualify SSAs. An indexed field is defined in 
hame only for an index target segment type. During DBDGEN, one indexed 
field is defined in the index target segment type for each secondary 
index that points to that segment type. The name specified for the 
indexed field actually represents the search field of the associated 
secondary index. Since the name specified for the indexed field of an 
index target segment type represents the search field of a secondary 
index, when an SSA is qualified on the indexed field of an index target 
segment, the search field of the associated secondary index is searched 
to satisfy the call. Qualifying calls on the search field of a 
secondary index is allowed when processing the data base through the 
secondary index. It is also allowed when the secondary index is 
specified in the INDICES operand of the SENSEG statement during PSBGEN. 
Otherwise, qualifying calls on the search field of a secondary index is 
not permitted. 


When a secondary index is searched to see if an index pointer segment 
satisfies a call, the call is satisfied when an index pointer segment 
contains th2 specified search field value and points to the index target 
segment under consideration. 
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In cases where index source segments are several levels below index 
target segments, qualifying calls on the search field of a secondary 
index can prove to be an efficient means of selecting index target 
segments based on data in index source segments. In no case should this 
use be made of a secondary index when the index target segments and 
index source segments are the same segment type, and the indexed data 
base is being processed through its primary processing sequence. Even 
where the index target and index source segment types are different, the 
following guideline should be used. The method should be chosen which 
causes the fewest accesses to the data base or index. 


Considerations 


In using secondary indexing, consideration should be given to the 
following: 


e When an index source segment is inserted into or deleted from a data 
base, a respective index pointer segment is inserted into or deleted 
from the respective secondary index. This maintenance occurs in all 
cases, regardless of whether or not the application program doing 
the updating actually uses the secondary index. 


e When replacing data in a source segment that is used in the search, 
subsequence or ddata fields of an index, the index is updated by 
IMS/VS to reflect the change. When data used in the ddata field of 
an index pointer segment is replaced in a source segment, the index 
pointer segment is updated with the new data. When data used in the 
search or subsequence fields of an index pointer segment is replaced 
in a source segment, the index pointer segment is updated with the 
new data, and in addition, the position of the index pointer segment 
within the secondary index is changed. The position is changed 
since a change to the content of the search or subsequence field of 
an index pointer segment changes the key of that segment. The 
secondary index is updated by deleting the segment from the position 
determined by the old key and re-inserting the index pointer segment 
in the position determined by the new key. 


e The use of secondary indexes will increase storage requirements of 
all steps which include within the PSB: 1) a PCB for the indexed 
data base, and 2) the processing option which allows the index 
source segment to be updated. The additional storage requirements 
for each index data base will range from 6K to 10K. A percentage of 
this additional storage will be fixed in real memory by VSAM. For 
additional information on storage requirements, refer to the topic 
"“IMS/VS Data Base Buffer Pools" the storage estimates chapter of the 
IMS/VS System Programming Reference Manual. 


e The use of a secondary index must be considered relative to 
alternate means of achieving the same function. AS an example, it 
may be desired to produce a report from an HDAM data base in root 
key sequence. A secondary index will conveniently provide this 
capability. However, the access of each sequential root will, in 
most cases, be a random operation. It would be a very time 
consuming operation to fully scan a large data base where each root 
access is random. It may be more efficient to scan the data base in 
physical sequence (GET NEXT not using a secondary index), and then 
sort the results by root key so that the final report can be 
produced in root key sequence. 


e A secondary index uses a key sequenced data set only if all index 
pointer segment keys are unigue, and a key sequenced and entry 
sequenced data set when index pointer segment keys are non-unique. 
Whenever possible, the data used for keys should be unique to 
eliminate the need for the entry sequenced data set, which in turn, 
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eliminates the additional I/0 operations required to search the 
entry sequenced data set. 


e When calls for an index target segment type are qualified on the J 
search field of a secondary index, and the indexed data base is not 
being processed through the secondary index, additional 1/0 
operations are required since the index must be accessed each time 
an occurrence of the index target segment type is inspected to see 
if that occurrence satisfies the call. Since the data contained in 
the search field of a secondary index is a duplication of data ina 
source segment, the user should determine whether or not an 
inspection of source segments in their data base might yield the 
same result faster. 


Variable length segments enable the user to vary the amount of 
storage space used to store different occurrences of the same segment 
type. They are intended for use by application programs that process 
variable length text or descriptive data. In addition in some cases, 
they can be used to enhance utilization of secondary storage. Variable 
length segments enable the user to vary the space used for each 
occurrence of a segment type between a minimum and maximum number of 
bytes through a two byte size field loaded with each occurrence. 


Variable length segments can be used in HISAM, HDAM and HIDAM data 
bases when VSAM is specified as the access method for the data base. To 
use variable length segments, a segment type must be defined as variable 
in length when defining the segment type through the DBDGEN utility. 
The variable length of a segment type is specified using the BYTES= 
keyword of a SEGM statement as shown in Figure 4-42, MAXBYTES specifies 
the maximum length used for the data portion of occurrences of a segment " 
type and MINBYTES specifies the minimum length used. In addition, the J 
user must include a two byte size field in the first two bytes of the 
data portion of each occurrence of that segment type when loading it 
into the data base. The size field is loaded with each segment to tell 
IMS/VS the length of data in that segment. Since the size field is in 
the data portion of a segment, the data length placed in the size field 
must include the length of the size field itself. In addition, if a 
sequence field is defined in the segment type, the minimum length 
specified in the size field must include at least the size field and all 
data to the end ef the sequence field. 


When initially loading occurrences of a variable length segment type, 
the space used to store the data portion of an occurrence is the length 
specified in MINBYTES or the length specified in the size field, 
whichever, is greater. When MINBYTES is greater than the length 
specified in the size field of an occurrence, more space is allocated 
for the segment than is required for the segment. The additional space 
allocated is free space that can be used when existing data in the 
segment is replaced with data that is greater in length. 
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Figure 4-42. Variable Length Segments 


Variable length segment formats are shown in Figure 4-43. Fixed 
length and variable length segment formats are the same except for a 
Size field placed in the data portion of a variable length segment. In 
addition for HDAM and HIDAM data bases, when the prefix and data 
portions of a segment are separated in storage due to update activitiy, 
the first four bytes of space following the prefix are used for a direct 
address pointer to the separated data portion of the segment. 


The user can load segments initially with a given number of bytes of 
data, and then either increase or decrease the length of data in each by 
replacing the data. When the length of data in an existing segment in a 
HISAM data base is increased, the logical record containing the segment 
is rewritten to acquire the additional space required. Any sagments 
displaced through the increased data length are placed in overflow 
storage. When the length of data in an existing segment in a HISAM data 
base is decreased, the logical record is rewritten to make all segments 
contiguous within the logical record. When the data in an existing 
segment in an HDAM or HIDAM data base is replaced with data that is 
greater in length and the space allocated for the existing segment is 
not sufficient for the new data, the prefix and data portions of the 
segment are separated in storage to obtain sufficient space for the new 
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data. When separated, a pointer is placed in the first four bytes of 
space following the prefix, which remains in its original position, to 
point to the new data portion of the segment. When separated and 
existing data is replaced with data that fits into the original space 
allocated for the data portion of the segment, the new data portion is 
placed in the original space allocated overlaying the data pointer. 

When the prefix and data portions of a segment are not separated, and 
data in an existing segment in an HDAM or HIDAM data base is replaced 
with data that is shorter in length, the new data followed by free space 
occupies the position of the original data, 
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Figure 4-43. Variable Length Segment Formats 


CONSIDERATIONS 


For HISAM data bases, replacing existing data in segments with data 
that is greater in length can affect performance since this may require 
displacing segments to overflow logical records. Replacing data in an 
existing segment in a HISAM data base with data that is shorter in 
length has no affect on performance. The additional overhead required 
to use variable length segments in a HISAM data base consists only of 
the two byte size field loaded with each occurrence. 


Additional storage requirements in HDAM and HIDAM data bases when 
variable length segments are initially loaded consists of the two byte 
size field in the data portion. [In addition when the prefix and data 
portions of a segment are separated in storage, a one byte segment code 
and one byte delete byte are stored with the data portion of the 
segment. Performance can be affected when the prefix and data portions 
of segments are separated and stored in different blocks in a data set. 
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CONVERSION CONSIDERATIONS 


When a segment type has been defined as variable in length, before 
initially loading or inserting any occurrence of that segment type into 
its data base, a size field must be present. To convert an existing 
data base from fixed length to variable length segments, a size field 
must be added to each segment before it can be loaded or inserted into a 
data base as a variable length segment. 


The user must supply his own routine to convert an existing data base 
from fixed length to variable length segments. For the new data base, a 
new DBD must be created that identifies the variable length segment 
types. The routine could then sequentially retrieve segments from the 
existing data base, add the size field to variable length segments, and 
then insert the segments into the new data base. 


A second method of converting from fixed length to variable length 
segments enables use of the IMS/VS Unload/Reload utilities; however, 
this method requires that an interim DBD be created. The interim DBD is 
required to enable a user routine to place a size field in fixed length 
segments before they can be loaded into a data base as variable length 
segments. 


For the interim DBD, the user specifies a fixed length for the 
segment type that is being converted to variable length. In addition, 
the user specifies use of the segment edit/compression exit for that 
segment type. Using the reload utility, each time an occurrence of the 
segment type is presented to an IMS/VS action module for loading, the 
segment edit/compression exit enables a user routine to gain control to 
add a size field to the segment. After the size field is added, the 
user routine passes control back to the action module which then loads 
the segment into the data base. After the data base is reloaded by the 
reload utility, the user then creates a new DBD to define the variable 
length of the segment types converted. 


SEGMENT EDIZT/COMPRESSION EXIT 
The segment edit/compression exit facility of IMS/VS enables the user 
to supply a routine to edit a segment during its movement between the 
application program input/output area and the data base buffer pool. 
The facility offers the user the ability to encode data for security 
purposes, to format data to be used by application programs, and to 
compress a segment to eliminate redundant characters. The 
edit/compression routine should be transparent to the application 
programs. 


The routine to be used for edit/compression is named by the operand 
COMPRTN= routine-name on the SEGM statement in the DBDGEN operation for 
the data base. A segment work area is constructed by IMS/VS at 
initialization time, and the edit routine is loaded when the data base 
is opened. AS a segment from that data base is requested by the user, 
its location in the buffer pool is obtained. If an edit routine has 
been specified, the address of the data portion of the segment, and the 
Start of the segment work area is supplied and tke routine is given 
control. On a retrieve operation, the edit routine is responsible for 
moving the data from the buffer pool to the segment work area. IMS/VS 
will move it from the segment work area to the application program I/0 
area. For load, insert, or replace operations, data is moved from the 
application program I/O area to the segment work area by the edit 
routine, then to the buffer pool by IMS/VS. See Figure 4-44 for a 
visual explanation of segment edit/compression. 


Data Base Design Considerations 4.125 
















RETRIEVE 9 LOAD/INSERT/REPLACE 
a 
za 
° 
INPUT > SUNT as — 
AREA ~~» J SIZE USER DATA o AREA Size USER DATA 
LFIELD 2 [FIELD 
as a (SOURCE) = 
a 
zt 
USER 
IMS g ROUTINE 
c EDIT 
I ROUTINE 
SEGMENT WORK O 
AREA a 
6 
rs) SEGMENT WORK 
AREA 


SIZE |EDITED 
FIELD| USER DATA 


IMS 


USER 
















ROUTINE 


BUFFER POOL BUFFER POOL 


SIZE EDITED 
FIELD} USER DATA 






SIZE EDITED 
FIELD | USER DATA 


Figure 4-4Uu. Segment Edit/Compression 


To assist the user in providing parameters to his edit/compression 
routine, the DBD control block has a table appended to it in the form of 
assembly language control sections. One control section is developed 
for each segment type to be edited or compressed. These control 
sections contain information such as the edit/compression routine nane, 
the name of the segment, and the total length of that control section. 
Each control section may be extended by the user to contain any desired 
data or algorithm information. 


Although the segments may be defined as fixed or variable length to 
the application program, the segments to be processed by the 
edit/compression routine must be variable length in the data base. The 
data length is contained in a size field in the first two bytes of the 
segment. If the segment is defined as fixed length to the application 
program, the size field must be stripped off by the edit/compression 
routine before the seqment is presented to the application program. In 
addition, if the segment was compressed, it must be expanded by the edit 
routine to the fixed length expected by the application program. In 
reverse, if the application program presents a fixed length segment, the 
edit/compression routine must append the size field prior to the segment 
being written to the data base. If the edit/compression routine 
compresses the segment, the size field must be updated to reflect the 
correct length. 
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To convert existing data bases to use this facility, the following 
steps must be performed: 


1. Unload the current data base using the reorganization/unload 
utility and using the current DBD. 


2.2 Define a new DBD which specifies VSAM as the access method and 
specifies a COMPRTN for those segments which are to be converted. 
Reload the data with the reorganization/reload utility. 


3. The named COMPRIN provided during reload should encode, compress 
or edit the segment {as determined by the installation's 
requirements) and add the two byte size field. 


There are two types of segment manipulation possible through the DL/I 
edit/compression facility: 


segment ina manner that does not alter the content or position 
of the key field. Typically, this type involves compression or 
encoding of data from the end of the key field to the end of the 
segment. This is the only time that the location of the fields 
may be altered. The segment size field of a variable length 
segment cannot be compressed. 


Key compression -- movement ot compression of any data within a 
segment ina manner that can change the relative position, value, 
or length of the sequence field as well as any other fields. 


Any segment type in a physical data base can be specified during 
DBDGEN as being compressible with either the KEY or DATA option, with 
the following exceptions: 


e Any segment type which is defined as a logical child may not be 
specified 


e Segments residing in an INDEX data base may not be specified 


e Segments defined as root segments of a HISAM data base may he 
specified for DATA compression only 


Although the contents of the sequence field or the data may be 
modified by the edit/compression routine, the segment's position in the 
data base is determined by the original sequence field value. An 
example may help tu explain this. If the defined sequence of a 
particular segment type is based on last names, and the data base 
contains segments for people named SMITH, JONES, and BROWN, the segments 
are maintained in alphabetical sequence -- BROWN, JONES, SMITH. Assume 
that an edit routine encodes these names as follows: 


BROWN-------- >29665 
JONES==<2---= >16552 
ShLThi==<-s2== >24938 


The encoded value is placed in the sequence field. The segments will 
be maintained in the original sequence (BROWN, JONES, SMITH) rather than 
in the numerical sequence implied by the encoded values (16552, 24938, 
29665). The records are maintained in the originally defined sequence 
so that if the application program issues a GET NEXT request, the 
correct segment is retrieved. This also applies to secondary index 
fields contained in index source segments involved in secondary 
indexing. 
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CONSIDERATEONS 


General considerations which apply to using the segment 
edit/compression exit facility ares 


e Any segment specified to be edited aust reside in a VSAM data set 


® All segment editing takes place on segrents described in a physical 
data base only 


e If the user routine is designed to edit more than one segment type, 
in one or more physical data bases, the routine aust be link-edited 
as reentrant 


e Adequate storage for the edit routine{s) must be provided for both 
batch and online systenus 


e Since this aodule becomes a part of the IMS/YS region, any abnormal 
termination on its part terminates the entire IMS/VS region 


¢ The user routine cannot eauploy such Operating System macros as SPIE 
and STAE 


The segment edit/comapression exit provides the user with a valuable 
tool. However, several additional considerations are worth noting. 
Edit/compression processing of each segment on its way to or from an 
application program involves added CPU time. In addition, the search 
time required to locate the requested segsaent may be increased, 
depending upon the options selected. In the case of full segment 
compression, using the KEY compression option, every segment type that 
is a candidate to satisfy either a fully qualified key or data field 
request must be expanded or decoded to allow examination of the 
appropriate field by the IMS/YS retrieve module. For key field 
qualification, only those fields from the start of the segment through 
the sequence field are expanded during the search. For data field 
qualification, the total segment is expanded. In the case of data 
compression and a key field request, littie more processing is required 
to locate the segment than that of non-compressed segments, since only 
the segment sequence field is used to determine if this segment 
occurrence satisfies the qualification. 


Other considerations can isapact total system performance, especially 
in an online teleprocessing environment. For example, being able to 
LOAD an algorithm table into memory will give the compression routine a 
large amount of flexibility. However, this action can place the entire 
IMS control region into a wait state antil the requested member is 
present in main storage. It is suggested that all alternatives be 
explored to lessen the impact of situations such as this. 


DATA BASE DESIGN CONSIDERATIONS 








HIERARCHICAL SEQUENTIAL DESIGN CONSIDERATIONS 


This section discusses the various data base design considerations 
with which programming personnel should be familiar to get the best use 
from the capabilities of the IMS/VS Hierarchic Sequential data base 
organization and in particular the HISAM data base access nethod. 
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PROCESSING TIME 


Before performing I/O operations, IMS/VS uses information within its 
internal data base tables and data base buffers in an attempt at 
satisfying segment requests. If no information is found in main 
storage, the index and the necessary primary data set record are read 
from auxiliary storage. In accessing a segment of information, a VSAM 
or ISAM index is used to obtain the root segment of the specified 
record. Dependent segments of that root are reached in a sequential 
manner. If the information is not found in a primary data set record, a 
pointer in the primary data set logical record causes a read to be 
performed on an overflow record. 
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Figure 4-45. HISAM Data Base Record in Auxiliary Storage 


The first solution to reduce the number of direct access references 
(and hence processing time) is to increase the size of the primary data 
set logical record length, thus eliminating the need for overflow 
records. 
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Figure 4-46. HISAM Data Base Record -- Larger Primary Data Set Logical 
Record 


The segment which is logically farthest from the root in the top to 
bottom, left to right, hierarchy, is also physically farther from the 
root when the segment is stored. This indicates that the logical 
structure may be manipulated to reduce the number of direct access 
references required to obtain a particular segment. 
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* The pointer is at the beginning of VSAM logical records 
Figure 4-47, Storage Sequence of Segments in HISAM Data Rase Record 


Another solution is the use of multiple data set groups. This allows 
second-level segments and their dependent segments to be accessed 
through an index with no need to access the root or intervening 
segments. The maximum number of data set groups for a data base is ten. 
The use of multiple data set groups is allowed for a HISAM data base 
only if ISAM/OSAM is the access method. See Figure 4-48, 
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Figure 4-48. HISAM -- Multiple Data Set Groups (ISAM/OSAM only) 


As can be seen, segments in the secondary data set group can he 
retrieved without reference to the primary data set group. 


Figure 4-48 shows that segments D, E, F, and G are placed into a 
secondary data set group. Figure 4-49 shows that, because no references 
to the primary data set group are necessary, the number of references 
needed to obtain Segment F with key 181 has been reduced. Note that the 
index in both data set groups contains the key value of the root 
segment. 
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Figure 4-49, HISAM Segment Storage -~ Multiple Data Set Groups 


With multiple data set groups, we may also elect to expand the size 
of the logical record of the secondary data set group as shown in 
Figure 4-50. In this case, no overflow logical record wonld be 
required. Logical record sizes of data set groups representing a single 
data base may vary. In addition, the logical record length of each 
primary data set and of its associated overflow data set in the same 
data set group may be equal, or the overflow logical record length may 
be greater than the primary logical record length. 
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Figure 4-50. HISAM Secondary Data Set Group with a Larger Primary Data 
Set Logical Record Length 


In summary: 


® Logical record size can be expanded to accommodate more segments, 
thus eliminating or minimizing the need for overflow records. 


e The logical structure can be manipulated to bring the most active 
segment types hierarchically closer to the root. 


e Multiple data set groups can be used to avoid accessing a root 
segment and intervening dependent segments when accessing a 
particular segment type. 


e The logical record length of primary and overflow data sets across 
data set groups may vary. The logical record length of an overflow 
data set must be equal to or greater than the primary logical record 
length in the same data set group. 


DIRECT ACCESS STORAGE SPACE UTILIZATION 


The percentage of utilization of direct access storage device space 
by an IMS/VS data base at load time is a function of the relationship 
between the logical record lengths and the size of the actual data base 
records being loaded. Data base records within a data base usually vary 
in size, but, since IMS/VS uses fixed-length logical records, the choice 
of a logical record length to contain the largest data base record 
results in unused space for the smaller data base records. Choice of a 
logical record length to hold the smaller data base records results in 
better space utilization in the primary data set, but parts of larger 
data base records are forced to the overflow data set on initial 
loading. 


The choice of a logical record length must be made with appropriate 
consideration for the type of processing to be accomplished against the 
data base. For example, if new dependent segments are being created 
with great freguency, it may be a good idea to assign an oversized 
logical record length. This logical record length allows many dependent 
segments to be placed in the primary data set. Figure 4-51 shows what 
happens if a small logical record length is chosen for two records -- 
Record 1 and Record 2. Two overflow records are required, and there is 
very little slack space. 
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Figure 4-51. HISAM -~- Small Logical Record Length 


\w Figure 4-52 shows the same records with a large primary data set 
logical record length. There is no requirement for overflow records, 
but there may be a large amount of slack space in primary data set 
logical records. All unused space in the primary data set is tied to 
specific roots. 
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DATA BASE RECORDS 
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Figure 4-52. FISAM -- Large Logical Record Length 


The slack space in Figure 4-53 can only be used by dependent segments 
of Root 24. New dependent segments of Root 18 would have to be put into 
overflow, even though the slack space related to Root 24 is not heing 
used and is in the same physical block. : 
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Figure 4-53. HISAM -~ Utilizing Slack Space 


Segmentation also influences utilization of direct access storage 
device space. See Figure 4-54, The minimum logical record length which 
can be assigned for the primary data set of the data base must be large 
enough to hold the root segment defined for the data base; the minimun 
logical record length which can be assigned for the overflow data set of 
the data base must be large enough to hold the largest segment defined 
for the data base. The following describes two different methods of 
segmenting for a 2000-byte record: Case A, where the ROOT and DEP! 
segments are combined into one 1500-byte segment, yields a minimun 
logical record of 1500 bytes and produces 1000 bytes of slack in a OSAM 
record. This slack is only available for dependent segments which 
relate to a particular root. The logical record sizes for overflow must 
be at least as large as the primary logical records. The different 
method of segmenting the same record in Case B, where the ROOT and DEP! 
segments are separate segments, yields a minimum logical record size of 
1000 bytes, with no excess in the overflow record. 
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ASSUME: DATA BASE RECORDS OF 2000 BYTES 
SEGMENTATION: 
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Figure 4-54. Data Base Record Segmentation Options 


Since the sizes of logical records in data set groups will probably 
be different, multiple data set groups can also be used for hetter 
utilization of DASD space provided that ISAM/OSAM is the access method. 
Figure 4-55 shows a data base record for a single data set group with 
segments of considerably different sizes. The primary logical record 
Size is 225 bytes; the overflow logical record size is 1500 bytes. 
Initially, no slack remains in the primary or overflow records. 
However, this choice of logical record size may leave 1450 bytes of 
slack in the overflow record when a new root is inserted after the 
initial load. This slack space will remain until other inserts cause 
the space to be used. 
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Figure 4-55. HISAM Single Data Set Group Segmentation 


Figure 4-56 shows the same record as Figure 4-55, except that 
multiple data set groups are used. The primary data set group has a 
primary and overflow logical record size of 225 bytes. The secondary 
data set group has a primary and overflow logical record size of 1500 
bytes. There is no slack space, and no overflow records in the overflow 
data set are used during initial load. After initial load, new segments 
can make optimal use of space in each of the different size overflow 
records of the two data set groups. 
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Figure 4-56. HISAM Multiple Data Set Group Segmentation 


The reader should remember that the logical record length of the 
overflow data set within a data set group must be equal to or greater 
than the logical record length of the primary data set. Also, the 
primary logical record length must accommodate the root segment, and the 
overflow logical record length must accommodate the largest segment in 
the data base. For secondary data set groups, the minimum logical 
record length must be expanded by the amount necessary to append 
sequence field keys of the root segment type upon occurrences of the 
first segment type defined in the secondary data set group. 


Both primary and overflow logical records can he blocked one or 
multiple logical records to a physical block. 
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DESIGN TRADEOFFS 


A review of the logical and physical structures supported by IMS/VS 


is recommended. : 


The IMS/VS Hierarchical Sequential organization supports the 
Hierarchical Sequential and the Hierarchical Indexed Sequential Access 
Methods (HSAM and HISAM). HSAM is based on BSAM and QSAM; HISAM, on 
VSAM or ISAM with an EXCP extension named OSAM (Overflow Sequential 
Access Method). The following discussion is based on HISAM. 


In Figure 4-57, each block represents a segment type, with the block 
at the top referred to as the root segment (A). The other segments, B, 


C, and D, are dependent segments. Root segment A is also level one, 
segments B and C are level two, and segment D is level three. 


ka 


1-255 SEGMENT TYPES 
1-15 LEVELS 


1 ROOT SEGMENT PER DATA BASE RECORD ; } 


0 TO N) DEPENDENT SEGMENTS PER PARENT 
1 TO N' SEGMENTS PER DATA BASE RECORD 


1 TO N' DATA BASE RECORDS PER DATA BASE 


Figure 4-57. Data Base Structure Rules 


The principal reason for the existence of dependent segments is that 
they give the user the ability (by variable-length records and dependent 
segments) to take care of information which it would otherwise be 
necessary to repeat from 0 to n times. 


Figure 4-58 shows the physical order of storage -- top to bottom ard 
left to right. As shown, this data base record begins in the primary 
data set and requires two additional logical records in th2 overflow 
data set. The two overflow records can be blocked within one overflow 
physical block. The technique of pointing from one record to another 
allows data base records within a data base to vary considerably in 
length, but for all practical purposes their size is unlimited. 
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Figure 4-58, HISAM Physical Storage -- ISAM, OSAM, or VSAM 


Primary and overflow data set logical records are always blocked one 
or more for each physical block (see Figure 4-59). A data base record 
may be contained in one primary data set logical record, or it may 
consist of one primary data set logical record and one or more overflow 
logical records. The overflow logical records must be at least as large 
as the primary logical record. Overflow logical records may be 
unblocked or blocked. The number of overflow logical records within a 
physical block may be equal or not equal to the number of primary 
logical records within a physical block. 
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Figure 4-59, HISAM Physical Storage Blocked One or Multiple 


VIABILITY OF DATA BASE DESIGN 


In the design of a data base, the designer must consider the 
viability of that design. How can he anticipate, at least in some 
measure, changes such as the additions of new data, new applications for ) 
new data, new applications for existing data, discontinuance of existing 
data, in short, the change in the level of activity against the data? 


In adding new data segment types, the simplest approach is to extend 
the data base to the right (see Figure 4-60). By the addition of new 
segment types in this manner, segments to the left and applications 
dealing with those segments need not be modified. An additional benefit 
for HISAM data bases, or HDAM and HIDAM data bases that use hierarchic 
pointers is that only the data base descriptions need to be regenerated. 
It is net necessary to unload and reload the data base. For HDAM and 
HIDAM data bases where the segment type being added will be pointed to 
by physical child pointers, it is necessary to unload and reload the 
data base to add physical child pointers to the prefix of the physical 
parent of the segment type being added. 
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Figure 4-60. Data Structure Change -- New Segment Type Defined at End 
of Hierarchy 
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In Figure 4-61, the few data, "Production Control" and "Work 
Station," could be added to the data base at a different position. A 
disadvantage of adding new segment types in this way is that the 
physical code of each segment type changes. The order of segment 
insertion being top to bottom, left to right, such a change would 
reguire a reload of the file. Again, there would be no reprogramming 
required for existing application programs. One reason for this 
arrangement could be that the majority of the processing activity is to 
be against the Production Control information. 
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Figure 4-61. Data Structure Change -- New Segment Type Defined within 
Existing Hierarchy 
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Pigure #-62 shows an arrangement that will almost certainly impact 
existing application programs, by making it necessary to regenerate the 
PSB for any program which is sensitive to "Standard Information." The 
degree of modification to the application program will, of course, be a 
function of the type of calls made against the data base and the use 
made of the concatenated key feedback information. ASsuming that no use 
is made of the concatenated key, the series of calls at the left would 
function properly without modification, after the PSB is made sensitive 
to "Production Control" and “Work Station." 
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Figure 4-62. Data Structure Change -- New Segment Type Defined Within 
a Leg of the Existing Hierarchy 


It is evident that the series of calls on the right side of Figure 
4-62 would not function properly. The unqualified GET NEXT call would 
obtain the "Production Control" segment instead of the "Standard 
Information" segment. 


In user applications with existing data, if the activity becomes 
weighted to the right it may be desirable to move certain segment types, 
logically and physically, nearer the root. This would ensure that they 
were located in the record containing the root segment. In the data 
base of Figure 4-63, an increase in activity against the Production 
Control segment could make a new data base design more desirable. 
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Figure 4-63. Data Base Structure -- Hierarchic Leg Independence 
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One solution, moving the segments logically and physically to the 
left, is shown in Figure 4-64. It is possible to plan for the freedom 
to move the legs of the data base around in this manner without 
affecting the functioning of application programs. If the data base and 
applications are designed in such a manner that each application program 
relates to the root and to only one leg of the data base, it is possible 
to manipulate the legs without impacting applications. 
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Figure 4-64, Restructured Data Base 
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Another solution to an increase in activity against certain segment 
types is to move those segment types to a secondary data set group. In 
this instance, however, the tradeoff against increased core buffer 
requirements would have to be considered. 


When segments representing a particular segment type cease to exist, 
there is no mandatory adjustment necessary to the data base design nor 
is there any measurable penalty for not doing so. Eliminating segment 
types, however, requires a new data base description generation. If 
there are no occurrences of the segment type in the data base and the 
segment types are farthest away from the root in the top to bottom, left 
to right fashion, there is no need to unload and reload the data base. 
In Figure 4-65, “Production Control" and "Work Station" could he 
dropped. 
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Figure 4-65. Data Base Structure -- Absence of Segment Types 


Eliminating segment types which are not logically last requires that 
the data base be reloaded. Program specification blocks which were 
sensitive to the segment types being deleted would be regenerated. 

Since the segment types are deleted because the applications and data no 
longer exist, there is no need to modify the majority of remaining 
application programs. The extent of the modification would in all 
probability be only a change in some call parameters to Data Language/I. 


Expanding the size of a segment can cause a change in the program 
{see Figure 4-66). On an individual application basis, this change can 
be avoided by using oversized work areas in the application program. As 
an example, a Data Language/I I/O area of 150 bytes could be defined 
when in reality the size of the segment to be operated on need only be 
190 bytes. With this technique, the size of the segment could be 
expanded without affecting the application program. It should be noted 
that the size of the application program will be increased, but this 
added overhead is usually more desirable than the possible reprogramming 
effort. 








}e— 100 BYTES —»| 


APPLICATION PROGRAM 






DL/I 1/0 AREA 


EXTENDED SEGMENT A 


|e-—— 150 Bytes ———>| 






Le 150 BYTES ———» 






Figure 4-66. Application Program I/O Work Area Size Considerations 
HIERARCHICAL DIRECT DESIGN CONSIDERATIONS 
The Hierarchical Direct organization is composed of two data base 


access methods: HDAM and HIDAM. The HIDAM access method uses two 
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physically distinct data bases for access and storage of the data. The 
INDEX data base is used to determine the sequence in which data is 
presented to an application program, but does not actually contain any 
of the data in the HIDAM data base. The HIDAM data base contains all 
the actual data and is physically distinct from the index. The HDAM 
access method uses one data base and a randomizing algorithm for 
accessing data. 


Design Considerations for the Index of a HIDAM Data Base 


The INDEX data base contains index segments which perform indexing. 
The content of the index segment is equivalent to the sequence field key 
in the root segment of a HIDAM data base. The INDEX data base used for 
HIDAM is composed of a single data set group which is similar to the 
HISAM organization. 


Since the INDEX data base is basically a HISAM data base containing 
only index segments, the majority of the design considerations from the 
HISAM section apply equally well to the index. Of course, both the 
primary or primary and overflow data sets should have relatively high 
blocking factors. For example, a quarter track of a 2314 for block size 
would be appropriate. The HISAM unload and reload reorganization 
program should be run fairly frequently against an INDEX data base to 
reduce long OSAM chains when ISAM/OSAM are the access methods. This 
procedure should not require an excessive amount of time, since the 
INDEX data base is much smaller than the HIDAM data base it references. 


Considerations for the design of the data portion of the HIDAM data 
base involve the tradeoff between direct access space and access time. 
The most efficient organization for access time, when application 
programs do not access every segment in any data base record, is to 
choose the physical twin/physical child manner of relating segments of a 
data base record. If this option is chosen, any path through the data 
base may be followed without looking at segments not on the path. The 
negative aspect of this choice is that more storage is needed than if 
the user elects the hierarchical pointer approach to relate segments. 


The hierarchical pointer option reduces prefix size by stringing 
together all segments of a data base record, but IMS/VS must process it 
in much the same manner that it processes HISAM. That is, the segment 
on the right of the structure is at the end of the hierarchical pointer 
chain. All segments to the left of a desired segment have to be scanned 
to get to the desired segment. Therefore, this option should be used 
for those portions of a data base record that are normally accessed 
sequentially. 


If root segments are often accessed sequentially, the user should 
probably select the bidirectional physical twin pointer option for root 
segments. if this option is chosen, and the user issues a data base 
call which references either implicitly or explicitly the next data base 
record, the index data base is not used to satisfy the request. 


Design Considerations for an HDAM Data Base 

The two major considerations in designing an HDAM addressing or 
randomizing algorithm are access time versus storage and reorganization 
considerations. Ideally, an addressing or randomizing algorithm spaces 
root segments across the root segment addressable area of a data base in 
such a manner that little storage is wasted and yet synonym chains are 
very short. Long synonym chains negate the savings made by not having 


Data Base Design Considerations 4,147 


to access an index. On the other hand, a sparse storage of root 
segments may waste direct access space that could be used if the 
organization were HIDAM. 


If a data base is increasing in size, some thought should be given to J 
reducing the problems when it must be reorganized. Some randomizing 
routines yield radically different results for the same set of keys when 
the size of the root segment addressable area is increased or decreased. 
If this is the case, the user is faced with the choice of loading 
randomly, which may be very slow, or doing an offline sort prior to 
reloading. Randomizing routines can be constructed that will not 
seriously alter the sequence of data when the size of the root segment 
addressable area is changed. An example of this is the binary halving 
routine illustrated in the IMS/VS System Programming Reference Manual. 


The user may wish to take advantage of the bytes parameter of the 
RMNAME= operand on the DBD statements for a DBD generation. The use of 
this parameter reduces the inefficiency caused by dependent segments of 
a very large data base record taking excessive space in the root segment 
addressable area. If excessive space is used for dependent segments, 
other root segments are forced out of their prime blocks in the root 
segment addressable area and into overflow. 


The use of bidirectional root segment physical twin chains is not 
recommended in HDAM, since roots are chained only off a root anchor 
point and thus do not tie the whole data base together as in HIDAM. 
Bidirectional pointers may cause additional processing time at insert 
time, since the NEXT root on the synonym chain must be updated to voint 
back to the root being inserted. However, use of the physical twin 
backward pointers provides improved delete performance, 


HDAM ~~ HIDAM CONSIDERATIONS FOR DEPENDENT SEGMENTS 


The user may wish to give some thought to the use of additional data J 
set groups in a HDAM or HIDAM data base to save access time and make 
better use of disk space. For example, a data base may contain a 
segment-typ2 which is quite bulky and infrequently accessed. This 
segment-type can be placed in a separate data set group, thus reducing 
access time among the more frequently used segment-types. 


Another form of separating segments into data set groups the user may 
Wish to investigate is separation by segment size. The Hierarchical 
Direct organization bit maps, which describe free space existing on 
blocks within the data base, contain information based on the maxinum 
segment size within the data set group. If segments of about the same 
size are contained within each data set group, better space utilization 
May result. 


Proper direct access data set block sizes is another factor to be 
considered in system performance. The larger the block size, the more 
data that is obtained with a single input/output operation. If the 
majority of the data is used, then larger block sizes have a good 
payoff. However, if the data is accessed randomly within a data base 
record and only small portions of any particular block are used, then 
the user has paid a penalty in terms of system channel time and core 
storage buffer space to access large blocks. 


MSZVS Use of BISAM/QISAM 
The IMS modules concerned with management of DL/I data bases make use 
of the OS BISAM and QISAM access methods. These access methods are used 


to access data stored in OS ISAM data sets. OS ISAM data sets are used 
by IMS/VS to store data for HISAM data bases and for the index data base 
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to a HIDAM data base. BISAM and QISAM are used by IMS under the 
following conditions: 


1. 


I/a 
IMS/VS 
always 
BISAM, 


BISAM is always used to manage an ISAM data set that is accessed 
from an IMS/VS CTL region (that is, in a message processing 
environment). 


The following rules apply to a batch processing environment only: 


a. QISAM is used to manage an ISAM data set of a HIDAM data hbase 
when the root segment of the HIDAM data base is referenced by 
one PCB only, and when the processing option for the root 
segment is retrieve or load only. In all other cases, BISAM 
is used to manage the ISAM data set of an index data base. 


b. BISAM is used to manage the ISAM data set of a HISAM data set 
group when {1) a PCB is sensitive to a logical parent that 
exists in the data set group, or (2) multiple PCBs are 
sensitive to segments within the data set group. Other data 
set groups will use QiSAM. Note, therefore, that for-a HISAM 
data base, BISAM may be used for some data set groups, while 
QISAM may be used for other data set groups. 


ce If use of both BISAM and QISAM is indicated for an ISAM data 
set by the rules presented above, use of BISAM takes 
precedence. 


d. If a user desires, for performance reasons, to cause IMS/VS 
to use BISAM to manage a particular ISAM data set, he can do 
so by ensuring the presence of one of the conditions outlined 
above that will cause use of BISAM. A user can cause IMS/VS 
to use QISAM for an ISAM data set only by ensuring the 
absence of any of the conditions that would cause IMS/VS to 
use BISAM. 


e. Note that, because of the rules described above, both BISAM 
and QISAM may be used during execution of a particular 
application program. 


buffers for data sets using BISAM are always obtained from the 
data base buffer pool. I/0 buffers for data sets using QISAM are 
Obtained by QISAM. If QISAM, use QISAM for read and writes; if 
use ISAM or OSAM for read, OSAM for write. 


UTILITIES 


DATA BASE RECOVERY 


IMS/VS supplies a number of utility programs designed to provide a 
rapid recovery of a data base data set rendered unusable because of 
read/write errors. Although these programs will be used infrequently, 
judicious preplanning will enhance data base availability in the event 
of failure. 


The 


1. 


data base recovery utility program set includes: 


A program to create an image copy or dump of a data base in a 
batch system. In addition, the online image copy utility allows 
increased IMS/VS availability by taking image copies of data 
bases in an online system. (For information on how to use and 
execute this utility, see "Online Data Base Image Copy Utility" 
in the "Data Base Image Copy Utility" section in the "Data Base 
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of an adequate data base buffer pool, CPU, and real storage 
resources to keep interference to the online workload at an 
acceptable level. Online image copy dynamically acquires storage 
and operates in a batch message processing region. This storage 
is used primarily for buffers for the SYSIN, SYSPRINT and the 
image copy data set(s). VST and SVS use two buffers per QSAM 
data set and MVS uses 5 buffers; these numbers can he increased 
with JCL statements. 


2. <A program to restore an image copy or dump of the data base. 


3. Logging routines in the IMS/VS batch and control regions to 
record on system log tapes any changes made to a data base. 


GY. A program to accumulate information from system log tapes about 
the latest changes to a specific data base. 


5. A program to rebuild the data base using, a) a previously created 
data base image copy, b) accumulated data base changes obtained 
from log tapes, and c) input from log tapes which have not been 
processed by the accumulation change progran,. 


The initial consideration in the use of these programs should be the 
frequency of data base image creations. The amount of data base 
activity and size of data base will determine the intervals between data 
set image copy creations. Since image copy input to the Data Base 
Recovery Utility provides the most rapid means of recovery, the shortest 
interval possible between image copy time and data base recovery is 
desirable. 


The second consideration should be the frequency of accumulation 
change creations. The accumulation change input provides a sorted, 
combined record of data base changes to be merged with the image copy. 
Since the sorted input is by physical block number within the data base, 
the application of the accumulation change input can be accomplished 
almost as rapidly as an image copy only. In addition, the accumulation 
change utility operates independently of IMS/VS, allowing the log 
changes to be accumulated without impacting data base availability. 


Since log change input is processed chronologically, random access to 
the data base being reconstructed is quite probable. The same physical 
record may be accessed multiple times in a single recovery. It becomes 
readily apparent that the accumulation of data base changes from log 
tapes with the accumulation program will greatly enhance performance of 
the data base recovery. 


See the chapter "Data Base Recovery Utilities" in the IMS/VS 


Base Recovery program set. 


DATA BASE REORGANIZATION 


Data base reorganization utility programs provide a convenient means 
for achieving physical and logical reorganization of IMS/VS data bases. 
Use of these facilities allows: 


e Recovery of direct access space occupied by deleted segments in a 
HISAM data base 


e Reorganization of a data base when the physical sequence of its 


segments has become different from its logical sequence because of 
insertion and/or deletion of segments. 
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e Physical and logical restructuring of a data base to better meet the 
requirements of IMS/VS application programs. Examples of 
restructuring of a data base include changing a data base access 
method and organization from HISAM to HIDAM, changing the physical 
placement of a segment type from one data set group to another, 
addition of segment-types, and addition or deletion of physical 
and/or logical intersegment relationships. 


The details of all the data base reorganization utilities are 
provided in the chapter "Data Base Reorganization/Load Processing" in 
the IMS/VS Utilities Reference Manual. 


Data bases may be reorganized separately, or several may he 
reorganized concurrently. If nonreorganized data bases are logically 
related with direct addresses to those being reorganized, then these 
must be scanned for all logical children whose logical parents are in 
one of the reorganized data bases. Programs are supplied to scan the 
nonreorganized data bases, and where necessary update their direct 
address relationships to a reorganized data base. 


The IMS/VS statistics programs provide data that can help systems 
Operation personnel determine whether a data base should be reorganized. 
Determination of an appropriate interval at which a data base is to be 
scheduied for reorganization depends, to a large extent, on systems 
operation personnel's knowledge of the overall activity on the data base 
(that is, the number of segment additions and deletions), of the 
physical organization of the data base, of the relationship of the data 
base to other data bases, and of the installation‘'s planned use of the 
data base in the future. 


Most data base reorganizations are done to recover space occupied by 
deleted segments and/or to physically resequence segments in their 
logical order. The number of segment insertions and deletions can be 
determined from data provided by the application accounting report, and 
the distribution of transaction response times as shown in the 
transaction response report. When segment chains become long, and when 
they involve segments that are in different areas of a storage device, 
response times tend to increase. Growing response times can indicate a 
need for data base reorganization. 


Frequency of reorganization should be considerably less for HDA™ and 
HIDAM than for HISAM data bases. HDAM and HIDAM both reuse space freed 
by deleted segments and both attempt to place inserted segments 
physically near their logically related segments (that is, near segments 
to which they are chained by physical child, physical twin forward, or 
hierarchical forward pointers). 


Reorganization of HISAM Data Bases 


Three methods can be used to reorganize HISAM data bases. A 
specially written user program can be provided, the IMS/VS-provided 
HISAM reorganization utilities can be used, or the IMS/VS-provided HD 
reorganization utilities can be used. 


The first method must be used when you want to accomplish data base 
structural changes that cannot be accomplished through the use of the HD 
reorganization utilities. The special program involves use of GET NEXT 
calls to retrieve segments from a data base, use of special user 
routines to accomplish the desired changes to the data base, and use of 
INSERT calls to reload the data base. Care must be taken in writing a 
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special reorganization -program so that concatenated key pointers, used 
for logical relationships, are properly maintained. 


The second method uses the HISAM reorganization utilities and should ) 
be used whenever a HISAM data base is to be reorganized with no changes. 
The HISAM reorganization is accomplished by a rapid unload/reload 
program that references data on a physical data base block level. The 
utilities drop deleted segments and then restore segments to the data 
base so that their physical sequence is the same as their logical 
sequence. External pointers that reference segments within the HISAM 
data base are unaffected, since they must be concatenated key pointers. 
Pointers within the HISAM data base that reference segments in other 
data bases are affected only if the other data bases are reorganized and 
if the pointers are direct pointers. Pointers contained in segments 
stored in the HISAM data base can be updated as described in the IMS/VS 


If structural changes are required, the third method should be used. 
This is described under Reorganization of HDAM and HIDAM Data Bases, 
following. 


Reorganization of HDAM an 


Several methods can be used to reorganize HDAM and HIDAM data bases. 
One method involves use of GET NEXT and INSERT calls with a user-written 
application program as described above. 


Another method is to use the IMS/VS~provided HD reorganization unload 
and reload utilities. These utilities use unqualified GET NEXT calls to 
sequentially unload segments from the data base to be reorganized. Data 
is appended to each segment to resolve logical relationships after doing 
the reload. After unload is completed, the segments are reloaded using . 
INSERT calls. At reload time, a check is made to determine if a segment 2 
is involved in logical relationships. If so, data describing the 
logical relationships is written to work tapes for later use in updating 
the logical relationship pointers. Note that the HD unload and reload 
utilities can be used to reorganize HISAM data bases, but that 
performance does not equal that of the rapid unload/reload utility. 
However, if structural changes are required, the HD reorganization 
utilities must be used. 


If the data base has logical relationships, the HD reorganization 
utility must be used to reorganize the data base, 


The reload utility also provides statistical data that can be used as 
described in the IMS/VS Utilities Reference Manual. 


PARTIAL DATA BASE REORGANIZATION 

The Partial Data Base Reorganization {PDBR) utility reorganizes 
user-specified ranges of a HDAM or a HIDAM data base. (A "range" is 
either a group of HIDAM records with contiguous key values or a group of 
HDAM records with contiguous relative block numbers, and is specified by 
using a low and high pair of key or block number values.) The Data Base 
Surveyor utility can be used to aid in the selection of the ranges to be 
reorganized. Full data base reorganizations are required less often 
because you are able to reorganize portions of a data base. PDBR is a 
process consisting of: 


e Step one which uses DBD and control information to build sets of, 
control tables, and optionally produces PSB source statements 
required for step two. 4 
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e Step two which reorganizes the key range(s) or area{s) of the data 
base specified by the user in step one including all logically 
related segments and their pointers. Statistical reports are 
produced by both steps. 


PDBR LIMITATIONS 
PDBR does nots: 
1. Permit data base structure changes, 


2. Reorganize HD or HIDAM data bases which are logically related to 
HISAM data bases which use a direct pointer in a logical child or 
logical parent segment. 


PDBR reorganization consists of: 
e Feading control statements that specify the range of records 
e Creating control tables for use by step two (above) 


e Determining logically related data bases that may require pointer 
resolution 


e Preparing a report 


STEP ONE: PRE-REORGANIZATION 


This step requires as input, the data base name to be reorganized, 
its DBD, and utility control statements defining the reorganization 
ranges and sort options. The primary output is the set of control 
tables to be used in the next step to perform the reorganization. 
Optionally, PSB source statements can be produced by creating a PSB in 
the next step. Additional outputs include reports, error messages, and 
a return code. 


STEP TWO: POINTER RESOLUTION 


This step reads the control tables produced in step one and the 
user-supplied control statements. According to the specified record 
ranges, all segments (roots and their dependents) are unloaded in 
hierarchical order to an intermediate data set. The space within the 
data base that these records occupied is freed. The records are 
reloaded into ranges of free space within the data base and the new 
record locations are saved in work records. Then all logically related 
data bases are scanned for pointers to the records that have been moved. 
Work records are created to designate where pointer resolution is 
required. All work records are then sorted (by OS/VS SORT) according to 
data base name and segment name. Finally, all pointers to the records 
having new locations are changed to point to those locations, 


Output from this step includes the partially reotganized data base, 
as well as a report of what was done and a return code. In the case of 
an unsuccessful execution, an error message is issued. For more 
information on reorganization and control statement examples, see the 
IMSZVS Utilities Reference Manual. 
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THE DATA BASE SURVEYOR UTILITY 


The user must determine the range of records in a data base to be 
reorganized and identify where to move the reorganized records. The 
Data Base Surveyor utility scans the data base to be reorganized and 
provides a report describing the physical organization and the use of 
free space. Using this report, an installation can determine the range 
of records to be reorganized and identify free space in the data base 
where the reorganized records can be moved. Surveyor analyzes the data 
base and produces a report which statistically summarizes chain length 
and free space information for user specified areas of the data base. 


USER RESPONSIBILITIES 


The purpose of using PDBR is to improve availability of the data 
base. The user should consider the trade-offs between reorganizing the 
entire data base or doing a partial reorganization. If the user decides 
to perform a partial reorganization, an area for reorganization must be 
selected and designated as a target area. If the user fails to select 
an area large enough, the execution of PDBR could defeat its purpose and 
in some cases, degrade performance. 


To have an effective reorganization of part of the data base, the 
user must at minimum know the information about the data base described 
in the following paragraphs. The Surveyor utility can be used to 
collect this information. 


The user must locate the data base segments that require 
reorganization. If the Surveyor utility is not used, an alternative is 
to analyze the insertion and deletion activities (or transaction 
patterns) that were applied to the data base. The application 
accounting information recorded on the system log can be used for this 
analysis. 


Once a range is identified, the user must calculate the average byte 
length of the data base records within the range to be reorganized. The 
purpose of this calculation is to estimate how much free space is 
required to hold those segments to be reloaded. A sampling technique 
could be employed here for efficiency. For a given range of data base 
records, the number of segments to be unloaded is usually unknown, since 
the number of occurrences of each segment type of a data base record is 
a variable. For HDAM, the number of root segments chained off of any 
root anchor point is also a variable. If the target area is different 
from the specified unloading range, the root will be chained off of the 
original root anchor point. 

The user must tabulate all the free space existing in the data base 
and look for a target area that is large enough. The user must also 
take into account all the space that will become available (the UNLOAD 
command frees the space occupied by a given segment) and select a 
sufficiently large target area. The target area may be the same area in 
which the data originally resided prior to Partial Reorganization. If 
such a target area does not exist in the data base, then the user must 
decide whether to extend the data base or to use the existing free space 
scattered in the data base. (Arbitrarily extending an existing data 
base is not a good practice as it increases the number of volumes of an 
already large data base.) If the choice is to use the existing free 
Space scattered in the data base, the user must consider whether the 
amount of existing free space is large enough to justify a partial 
reorganization. 


If the existing contiguous free space can hold only a small 


percentage of the total segments to be reloaded, the remainder will be 
scattered in different blocks throughout the data base by the insertion 
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process. If, however, the existing contiguous free space can hold a 
high percentage of the total segments, the reorganization might be 
effective and the operation should be performed. 


The user must estimate the time required to reorganize a range of the 
data base. In general, it takes a great deal more than 10% of the 
normal reorganization time to reorganize 10% of the entire data base. 
This is especially true when the data base to be reorganized has a 
substantial amount of logical relationships. If any scan actions are 
required to be done or if the decision is made to scan segments (based 
on the step one option report), SCAN is performed. The SCAN process 
accesses and examines every occurrence of a given logically related 
segment type regardless of the number of the data base records being 
unloaded or reloaded. If logical relationships exist within the large 
data base being partially reorganized, SCAN will access all the segments 
in the data base, even though only a fraction of the data base is 
actually being reorganized. AS with any reorganization, it is 
recommended that the data base be protected by a backup copy before and 
after a partial reorganization. 


OTILITY CONTROL FACILITY 


IMS/VS also supplies the Utility Control Pacility (UCF). The UCF 
directs the data base initial load, reorganization, recovery, and change 
accumulation utilities, and provides for restart processing after a 
utility failure or a user request to end processing. 


The UCF provides a method of performing most data base utility 
Operations and maintenance in preparation for recovery and 
reorganization under the control of one job, one step, and in one 
scheduling. It handles the data base recovery and data base data 
manipulations in reorganization, the combining of data base data changes 
into composite change records in change accumulation, and backup copy 
processing. Restart processing is invoked by an EXEC parameter or a 
control statement, and normal processing is directed by control 
statements. 


Manual for a full description of 


When direct access storage is required for a data base, the amount of 
space needed and the device type must be specified. IMS/VS follows the 
same approach as 0OS/VS. 


The amount of space required can be specified in terms of blocks, 
tracks, or cylinders. If it is desired to maintain device-independence 
across direct access types, space reguirements should be specified in 
terms of blocks. Otherwise, if the request is in terms of tracks or 
cylinders, such items as their capacity must be considered. ISAM data 
sets must be allocated by cylinder. The amount of space is supplied in 
the DD statement for the data set. 


Allocating the space for an IMS/VS data base that uses ISAM and OSAM 
(HISAM and INDEX) is similar to allocating space for an operating system 
indexed sequential data set; similar because an operating system data 
set can be divided into three areas, prime, index, and overflow. The 
three areas of an IMS/VS data base are index, prime, and overflow. Each 
data set group of a HISAM data base requires a primary and overflow data 
set to be allocated. 
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Allocating the space for an IMS/VS data set that uses only OSAM [{HDAM 
and HIDAM) is similar to allocating space for an operating system direct 
(BDAM) data set. Each data set group of an ADAM or HIDAMN data base 
requires one OSAM data set to be allocated. 


DBD generation computes, from the user's definition of segment 
frequency, the logical record length and/or block size of a data hase. 
It considers the device and rounds to the next higher one-fourth track, 
one-third track, one-half track, or full track. 


DBD generation also computes from the user's definition of segment 
freguency the space allocation requirements for a HISAM or INDEX data 
base. 


For use by Systems Operation personnel, IMS/VS has two parameters 
that can be inserted when a DBD generation is performed. These provide 
an additional means of specifying the logical record size (RECORD) and 
blocking factor (BLOCK) for a data set group within the data base. 
Instead of DBD generation specifying the logical record size and block 
size, it can be overridden by specifying the RECORD and the BLOCK 
parameters in the DATASET control card. kefer to the IMS/VS Utilities 
Reference Manual for details. 


ALLOCATION CONSIDERATIONS 


Space allocation should be considered with regard to the data base 
structure, the application programs that will access that structure, and 
the tools of IMS/VS DBD generation. The following discussion deals with 
a direct access device. 


When an IMS/VS data base is loaded on a direct access device, it is 
necessary to allocate space for that data base with JCL data definition 
statements. The creation of a HISAM or INDEX data base may require up 
to three DD statements, one each for the index, prime, and OSAM overflow 
areas. This discussion should provide assistance in initially 


determining the amount of space to allocate to these areas for any 
specific application. 
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Figure 4-67. Logical Record Length Distribution 


The graph in Figure 4-67 indicates that 50% of the logical records 
are 150 bytes or less in length, 70% of the logical records are 200, 
bytes or less in length, and 100% of the logical records are 600 bytes 
or less in length. 
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With fixed-length ISAM, it is necessary to establish a fixed value 
for LRECL in the prime area. If a value of 600 bytes is selected for 
LRECL, all logical records can fit in the prime area. However, 90% of 
the records then have at least 100 bytes of slack or wasted spaces; 70% 
of the logical records have at least 400 bytes of unused space. 


In this example, if a value less than 600 bytes is selected for the 
LRECL value, the ISAM prime area is not capable of holding all the 
logical data base records. Those dependent segment occurrences that do 
not fit in an ISAM prime logical record are housed in OSAM overflow 
records. Therefore, the determination of an ISAM prime logical record 
length must consider the tradeoff between storage in the ISAM prime area 
and in the OSAM overflow area. 


To determine a best balance between ISAM prime and OSAM overflow, the 
following points must be considered: 


1. Access to data that is wholly contained in the prime area is nore 
rapid than access to data contained in the two areas. Access is 
even slower to those logical data base records that require more 
than one overflow record. 


2. Disk space allocated to OSAM overflow can be used to hold segment 
occurrences that overflow from any logical data base record. 
Unused space in the prime area is tied to specific roots. 


3. Records may be blocked in the prime area and in the OSAM overflow 
area. The logical record length in the OSAM block must be equal 
to or greater than the ISAM logical record length in the same 
data set group. 


4 The nature of the accesses to the large logical data base records 
also has an important effect. If the larg2 logical data base 
records are highly used, the value of the prime LRECL should be 
increased to completely house more logical records, and the total 
size of overflow should be reduced. If the large logical data 
base records are infrequently accessed, an opposite shift should 
be made to increase the use of OSAM overflow. 


Considering these relevant factors for a specific data hbase, a 
percentage balance must be established between the ISAM prime and the 
OSAM overflow. For example, it may be hest, in the context of 
Optimizing space and time utilization, that 90% of the logical data base 
records completely fit in the prime area and 10% require some OSAM 
overflow storage. After this percentage is selected, the frequency of 
dependent segment occurrences is developed for the 90% percentile of the 
parent segments. The 90% is an estimated value for this specific data 
base. 


When space is allocated for a data base which uses only OSAM [HDAM or 
HIDAM) for data segment storage, DBD generation selects the appropriate 
physical block size for storage. Since space within physical blocks can 
be shared by segments from different data base records, logical record 
definition is not utilized. 


The number of physical blocks, tracks, and/or cylinders which should 
be defined in the JCL statements for any IMS/VS data base allocation can 
be estimated in the following manner: 


e Calculate the average data base record length (sum of segment 
lengths times frequency). 


® Calculate the number of logical records and physical blocks (HISAM 


or INDEX) or physical blocks {HDAM or HIDAM) required to store a 
data base record. 
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e Multiply the number of physical blocks per data base record times 
the number of data base records. 


e The result should provide an estimate for minimum space allocation. ) 
In addition to this value, space must be provided for additions to 
the data base after initial load. 


e If distributed free space was specified in the DBD, then multiply 
the minimum space allocation by: 


wit. X _fbft_ 
1-£spft fbff-1 
100 
wheres 


2 << £b£E < 100 or EFF = 0 and O < Fspf < 100 
See "Dataset Statement" in the chapter "Data Base Description," in 


the IMS/VS Utilities Reference Manual for more information on fbff 
and fspf. 
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CHAPTER 5. DESIGN CONSIDERATIONS FOR THE MULTIPLE SYSTEMS COUPLING 


(MSC) FEATURE 


This chapter describes the Multiple Systems Coupling (MSC) feature 
and contains design considerations for its use. Familiarity with the 
preceding chapters of this manual is assumed. 


The MSC feature provides the ability to connect geographically 
dispersed IMS/VS systems in such a way as to allow programs and 
operators of one system access to programs and operators of the 
connected systems. Communication between two or more (up to 255) IMS/VS 
systems running on any combination of OS/VS1 and OS/V¥S2 MVS systems in 
one or more System/370 CPUs is permitted. 


The MSC feature also provides a way to extend the throughput of an 
IMS/VS system beyond the capacity of a single System/370 Model 168MP. 
This is possible if the IMS/VS applications can be partitioned among 
systems such that either: 


e Applications execute in more than one system with data base contents 
split between systems (horizontal partitioning). 


e Applications execute in one system with the complete data base, that 
they reference, attached to that system (vertical partitioning); the 
transactions can originate in any system. For information on the 
use of the MSC feature in conjunction with the Fast Path feature, 
see the ''Fast Path and IMS/VS Interrelationships!' section of the 
chapter, *§'Design Considerations for the Fast Path Feature.!'! 


RELATIONSHIP OF A DB/DC/MSC SYSTEM TQ A SINGLE DB/DC SYSTEM 


In addition to the considerations for a single DB/DC system described 
in the previous chapter, major design considerations for MSC are: 
determining how to distribute functions among systems and obtain 
acceptable performance, defining valid connections between the systems, 
and implementing operating procedures for maintaining consistent 
connections. 


The flow of a transaction through processing in a nultisysten 
environment requires a few steps in addition to those required in a 
Single system environment. The additional steps can be identified by 
comparing Figures 5-1 and 5-2. 
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Figure 5-1. Single DB/DC System Transaction Flow 


Design Considerations for the MSC Feature 5.1 


Processing 








System ee 
IMS/VS Scheduling 
{ 
Message Rowlicni Message 
Gucue pplication Program Oicue 
DL/1 
MSC Support MSC Support 
t 1 
Access Method Access Method 
Terminal 
System 


Access Method 
1 


Access Method 
t 


MSC Support MSC Support 





ee 







MFS 

M 
IMS/VS Device Support Message essage 
t Queue Queue 


Access Method 





IMS/VS Device Support 
1 . 
MFS 

1 

Access Method 








Terminal 


Figure 5-2. Multiple DB/DC Systems Transaction Flow 


OVERVIEW OF THE MSC FEATURE 


itd 


This section presents a general description of the MSC feature and 
introduces MSC terminology. To do this, an example is used of a 
multisystem environment consisting of three systems -- System A, System 
B, and System C. Figure 5-3 shows the sample environment. 
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Figure 5-3. A Sample Configuration of Three Systems 


In a multisystem environment, the term local system is used to 
identify a specific system within the multiple configuration. All other 
systems are considered remote systems. For example, if we were 
considering the activities required by System B when it receives a 
message, Systen B is the local system and Systems A and C are remote 
systems. 


When the multisystem environment is defined, the items defined for 
each local system include: 


e All transactions received by and/or processed by that system 


e All logical terminals attached to this system and all logical 
terminals in remote systems that are referenced by transactions 
processed in this system or by terminal operators 


e The physical and logical connections between this system and the 
remote systems that share in the processing of the specified 
transactions 


LINKS 


The connection between two systems is called a link. All links must 
be defined during the IMS/VS system definitions for each IMS/VS systen. 
There are two types of links, physical link and logical link. A 
physical link is the actual hardware connection. A logical link is the 
mechanism through which a physical link is related to the transactions 
and terminals that make use of that physical link. The assignment of a 
logical link to a physical link can be specified during system 
definition, or made dynamically during system execution. 
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Physical Link 


A physical link is defined by the MSPLINK macro instruction. Three 
types of physical links are allowed by the MSC feature: 


e Binary synchronous communication (BSC) line 
e Channel-to-channel (CTC) adapter (OS/VS2 MVS only) 
e Main storage-to-main storage (MTM) 


Only the BSC line and CTC adapter represent actual hardware links. The 
MTM Link is a software link between IMS/VS systems running in the same 
System/370, and is intended primarily for backup and testing purposes. 
Physical link buffer sizes must be equal and if BSC is chosen for the 
physical link, CONTROL=YES must be specified for one end of the physical 
link and CONTROL=NO must be specified for the other end of the physical 
link. Figure 5-4 summarizes very simply the three types of physical 
links. 
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Figure 5-4. Summary of Physical Link Types 


One System/370 CPU may be linked to another CPU by one or more of 
each physical link type, as shown in Figure 5-5. The MTM link is 
recommended when two or more IMS/VS systems reside in one Systen/370. 
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Figure 5-5. Multiple Physical Links in One System/370 CPU 
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Or, multiple links may exist between CPUs. See Figure 5-6. 





Figure 5-6. Multiple Physical Links in Multiple System/370 CPUs 


Logical Link 


A logical link is defined by the MSLINK macro-instruction. A logical 
link relates a physical link to the transactions and terminals that can 
use that physical link. Each system in a multisystem configuration has 
one or more defined logical links. Two IMS/VS systems defined to 
communicate with each other, each through a specific logical link, are 
called partners. To establish connection between two IMS/VS systems, 
each partner must have a logical link definition. The two logical link 
definitions must specify the same partner identifications and be 
assigned to the same physical link. IMS/VS system definition assigns a 
number to each defined logical link. Logical link numbers are assigned 
sequentially, beginning with !t, in the order in which the links are 
defined. A logical link can be reassigned to a different physical link 
but the two systems must always communicate through a logical link 
partnership. 


IMS/VS system definition does not require that a physical link be 
specified for each logical link. The assignment of the physical link to 
the logical link can alternatively be made online using the IMS/VS 
/MSASSIGN command. There can be no communication between partners until 
the assignment is made. 


A logical link definition must include one or more logical link 
paths. Logical link paths are described in this chapter under the 
heading “Logical Link Path." 


If any logical terminals in a remote system are referenced by 
messages originating in the local system, the logical link definition 
must also include NAME macros to identify those remote logical 
terminals. 

Figure 5-7 summarizes the relationships of one physical link to one 
logical link to multiple logical link paths. Although more than one 
logical link can be defined with each physical link, only one logical 
link to physical link relationship can be assigned at any one time. 
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MESSAGE ROUTING 


The message routing function of the MSC feature supports transaction 
processing by more than one system, transaction processing by more than 
one application program in the same or different systems (by 
program-to-program switches), and message switches between terminals in 
the same or different systems. Conversational processing is available 
to any system in a multisystem configuration to the same extent as ina 
single systen. 


Routing Path 


The route through which IMS/VS passes a message from its origination 
through processing is called a routing path. One or more systems may be 
inciuded in a routing path. The routing path defined depends on the 
multisystem configuration and the functions assigned to each systen. 


The path between any two systems is called a logical link path. One 
or more logical link paths must be defined for each logical link. A 
identification for the system where messages using this path are to be 
processed and specifies a system identification for the system being 
defined. 


Each system in a multisystem configuration has one or more unique 
system identifications [SYSID) ranging from 1 to 255. SYSID assignments 
are implicit based on the logical link paths defined by MSNAME macros. 
For example, here are two MSNAME definitions: 


e MSNAME SYSID=(2,1) 
e MSNAME SYSID=(3,1) 


The first definition above says that messages using this logical link 
path are processed in the remote system whose local SYSID is 2. The 
second definition above says that messages using this logical link path 
are processed in the remote system whose local SYSID is 3. By way of 
these definitions, IMS/VS system definition assigns SYSID 1 to the 
system being defined and recognizes two remote systems with SYSIDs of 2 
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and 3. If a third path were defined with SYSID=[(5,4%), IMS/VS would also 
assign SYSID 4&4 to the local systen. 


Each system maintains a SYSID table containing all logical link paths 
defined in that system. The size of this table is determined by the 
highest SYSID defined and it will contain gaps for SY¥YSIDS that are not 
defined. 


Transactions are assigned to logical link paths in the APPLCTN macro 
definition. Consider the following application definitions, each with 
one transaction code defined: 


APPLCTN PSB=A 
TRANSACT CODE=A 

APPLCTN PSB=B, SYSID= (2, 1) 
TRANSACT CODE=B 

APPLCTN PSB=C, SYSID= (3, 1) 


TRANSACT CODE=C 


The SYSID keyword identifies the logical link path to be used for the 
transactions associated with the application. Transaction A is 
indicates transaction A is totally processed by the system being 
defined. Transactions B and C are remote transactions. Relating the 
application definitions to the previous MSNAME definitions, IMS/VS would 
return via SYSID 1, responses from transactions B and C to the systen 
being defined unless the application program specified an alternate 
destination for the response. 


Since inconsistencies among SYSID definitions may exist between 
various system definitions, IMS/VS provides offline and online methods 


-of verifying SYSID assignments. The Multiple Systems Verification 


utility is provided for offline execution to verify the consistency of 
definitions prior to attempting online system execution. Using this 
offline utility, consistencies among all systems in the multisysten 
configuration can be verified in one execution. You should use this 
utility to verify the MSC configuration each time an individual systen 
is redefined. The /MSVERIFY command is available for online use to 
identify and display inconsistencies between two systéms. 


Logical Destinations 


a Single system environment. A destination is either a logical terminal 
or a transaction code. It is considered a local destination if it 
resides in the local system and a remote destination if it resides in a 
remote system. In a multisystem environment, each system knows (by way 
of system definition) all local destinations and all remote destinations 
that may be referenced in this system. IMS/VS system definition 
requires that all local and referenced remote destinations be defined 
with unique names. 


Message routing is automatic according to the defined scheme unless 
routing exit routines are employed for dynamic routing control. Routing 


exit routines are described later in this section. 


Input and Destination Systems 


To introduce the terms used to describe message routing, let's look 
again at the sample configuration. Assume a message with a transaction 
destination is entered into Terminal X attached to System A. The 
transaction is defined to be processed by System B with its reply to be 
returned to the originating terminal. 
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Refer to Figure 5-8. On input, System A is considered the input 
system because the input terminal (Terminal X) is attached. System B is 
considered the destination system. The message is considered a primary 
request until processed. If the application program inserts a message ) 


with a transaction code destination during processing, this message is 
considered a secondary request. A message sent to the input terminal by 


A 
Input 
Terminal Input Destination 
System System 
Figure 5-8. Input Terminal and Input System on Input 


Refer to Figure 5-9. On output, System A is considered the 





Destination 
Terminal Destination 

System ) 
Figure 5-9. Destination Terminal and Destination System on Output 


Refer to Figure 5-10. Assume the transaction were defined to 
originate in System A but be processed by System B with its output being 
sent to Terminal Y attached to System B. In terms of message routing, 
this example is the same as the previous one for input. For output, 
however, System B is considered the destination system and Terminal Y is 
considered the destination terminal. 





Input Destination 
Terminal Input Destination Terminal 
System System 


Figure 5-10. Input from and Output to Different Terminals 


Intermediate System 
Another term related to message routing is intermediate system. Four 


systems linked as shown in Figure 5-11 illustrate an intermediate 
system. 
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Input Intermediate 


System System 
A 
Input 
Terminal 
C 
Intermediate Destination 
System System 


Figure 5-11. An Intermediate Systen 


Assume that a message originating in System A is defined to be 
processed and replied to in System C. To reach System C (destination 
system) from System A (input system), the message must be routed through 
either System B or System D as defined by system definition. In this 
instance, either System B or System D is considered the intermediate 
system. By referencing the SYSID table, the intermediate system routes 
the message to the next link toward the destination system. Whenever 
there is no direct link between the input and destination systems, there 
is always at least one intermediate system. If the configuration had 
just three systems but the link between Systems A and C was unavailable, 
a message could be routed through System B as the intermediate system by 
reassigning the appropriate links. 


The definition of each transaction code identifies the priority used 
to send the transaction to the processing system and the response back 
to the input system. Based on the specified priorities, three priority 
groups are considered during processing: 


e High priority is assigned to primary requests in the input system 
whose specified priority is 8 through 14. 


e Medium priority is assigned to secondary requests, responses and 
primary requests in an intermediate system, and primary requests in 
the input system, whose specified priority is 7. 


e Low priority is assigned to any requests in the input system whose 
specified priority is 0 through 6. 


In each priority group, message priority is based on the current 
transaction priority specified in the input system for primary requests 
and in the most recent processing system for secondary requests and 
responses. 


Stopped Transactions 


If a destination transaction code is stopped for queueing, the action 
taken by the destination system varies based on the type of request: 


e For a primary request that is not conversational or that starts a 


conversation, IMS/VS sends an error message to the input terminal and 
cancels the message. 
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e For a primary request that continues a conversation or a secondary 
request, IMS/VS queues the message. If the request is the first one 
received for that stopped transaction, IMS/VS also sends a message to 
the master terminal at that transaction's local systen. 


Message routing is automatic according to the defined scheme unless a 
routing exit routine is provided by the user. The routing exit routine 
is called before the message destination is verified. There are three 
types of routing exit routines: terminal routing, link routing, and 
program routing. 


called on terminal input. This routine can inspect the destination 
specified and, if desired, change it to any local or remote destination. 
This routine may examine the first segment of the message to determine 
what the destination of the message should be. If this routine does not 
change the destination, the originally specified destination is used for 
routing. IMS/VS will not call a terminal routing exit routine for 
commands, for any message received from a terminal in preset destination 
mode, or from a terminal that is continuing a conversation. 


In a configuration with horizontally-partitioned applications, the 
terminal routing exit routine could be used to screen all input messages 
and route them to the appropriate processing system based on information 
in the first segment of the input message. If transactions and links 
are appropriately defined, this routine might also be used to compare 
the load on the link associated with the specified transaction with 
other links. The message could be routed to a less-busy link. 


The link routing exit routine can be used to determine the 
destination (system message block) when the transaction arrives at the 
processing IMS/VS system, thereby minimizing the number of remote 
transaction definitions per system. This exit routine is called when 
the transaction reaches the remote processing system. It can inspect 
the transaction code and if desired, change it to another transaction 
code with the same attributes. This routine can examine the first 
segment of the message to determine what the new transaction code should 
be. If the routine does not change the transaction code, the 
destination remains the originally specified transaction code. 


program issues a change call while processing a transaction that 
originated in a remote system. This routine can request that an output 
message be returned to the input system for destination verification. 
This allows the application program to reply to a remote logical 
terminal without requiring the processing system to know the logical 
terminal name, thereby minimizing the number of remote logical terminal 
definitions per system. If two systems use the same logical terminal 
names for the master terminal, the program routing exit routine can also 
be used to send a message to the master terminal of either the local 
System or the input system. It should not be used for 
program-to-program switches since the routing for transaction processing 
is specified during IMS/VS system definition. If the program routing 
exit routine is not used, the destination specified in the change call 
must be defined in the processing system. Conversational programs 
cannot use the program routing exit routine. 


Remote Destination Verification 
fo maintain system integrity and prevent erroneous operation, an 


IMS/VS system in a multisystem configuration verifies all specified 
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destinations. Remote destination verification occurs on input from a 
terminal or upon receipt of an application program reply if a remote 
destination is specified for the message. The routing exit routine, if 
available, has completed. 


Destination verification occurs as follows: 


Destination Type Verified For 

Logical terminal e Destination types: The original 
destination must have been a logical 
terminal. 

Transaction ° Destination type: The original 
destination must have been a 
transaction. 


e Transaction attributes: The following 
attributes must be consistent in the 
transaction definitions in the input 
and destination systems: 


- ingquiry/noningquiry 

- Single segment/multiple segment 
= recoverable/nonrecoverable 

- conversational/nonconversational 


Conversational transactions must have 
fixed-length SPAs; SPA size must be 
the same for all transactions that 
participate in a conversation. 


When an invalid destination is recognized, IMS/VS cancels the 
message, sends an error message to the input terminal and to the master 
terminal of the local system, and logs an invalid request. If the 
message is conversational, the conversation abnornal termination exit 
routine is called in the input system and the conversation is 
terminated. 


Application Program Abnormal Termination 

When an application program abnormally termiantes, and the abnormal 
termination is not the result of a deadlock situation, a DFS554 message 
is sent te the master terminal of the system where the abnormal 
termination occurred. If the input message is still available, an error 
message that includes the first portion of the input message is sent to 
the input terminal. When the error message to the input terminal is 
sent, the DFS554 message includes the logical terminal name of the input 
terminal. 


CONVERSATIONAL PROCESSING 


Conversational processing is available to terminals attached to any 
system in a multisystem configuration to the same extent as in a single 
system. All transactions used in a conversation must be defined as 
conversational in each system of the multisystem environment. The input 
system controls the conversational resources for the duration of the 
conversation. When the input system receives a conversational 
transaction, it inserts the scratchpad area (SPA) as the first message 
segment and routes the message to the destination application progran. 

Each conversation step can be processed by any system of the 
multisystem configuration. Program-to-program switches can be routed 
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from system to system. SPAs used in multisystem conversations must be 
defined as fixed-length to allow IMS/VS to avoid SPA data set updates 
trom a remote system for program-to-program switches. The SPA size 
specification must be the same for all transactions that participate in 
the conversation. 


For the most part, multisystem conversations are transparent to 
terminal operators and application programs. One exception is if a 
conversational program inserts a message to a response alternate PCB in 
a remote system. By implication, this destination is in the input 
system and will, therefore, be verified by the input systen. 
Destination verification in this instance includes assuring that the 
specified logical terminal is still assigned to the inputting physical 
terminal. If the logical terminal has been reassigned, the input system 
invokes the conversation abnormal termination exit routine and 
terminates the conversation. No statas code is returned to the 
application program. 


The other exception is if an application program that does not 
execute in the input system uses the SPA to specify a transaction code 
and thereby pass conversation control to another program. If the 
specified transaction code is invalid, the input system invokes the 
conversation abnormal termination exit routine and terminates the 
conversation. No status code is returned to the application progran. 


Routing Exit Routines 


A terminal routing exit routine may be used for the input message 
that starts a conversation. It is not applicable at any other 
conversational step since the application program, not the input 
terminal, provides the destination for continuation of the conversation. 


A program routing exit routine cannot be used during conversations. 


Remote Destination Verification 

Destination verification for program-to-program switches occurs in 
the system where the program requesting the switch executes. If valid, 
that system sends the SPA and the message directly to the destination 
transaction. If invalid, that system returns a status code to the 
application program. 


Destination verification for a message to the input terminal is 
performed by the input system. The logical terminal specified must 
still be assigned to the inputting physical terminal. The input system 
also verifies the next transaction specified in the SPA. If the 
destination is invalid, the input system invokes the conversation 
abnormal termination exit routine and terminates the conversation. No 
status code is returned to the application program. 


Normal Conversation Termination 


A conversation can be terminated by either the application program or 
by the terminal operator. An application program normally terminates a 
conversation by inserting a message to the input terminal with a SPA 
that contains either no transaction code or the transaction code of a 
non-conversational transaction. The terminal operator terminates a 
conversation by entering either the /EXIT or /START LINE command. 


ad 
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The /EXIT command can be used any time during the conversation but 
the conversation is not terminated until the current conversational step 
has replied to the input terminal. This means that all data base 
processing for the current step is accomplished before a conversation 
ends. 


If the input system is shut down and subsequently cold started, all 
the conversations that it controls are lost. It cancels any 
conversational messages it receives for input terminals previously 
involved in active or held conversations. 


As in a single system environment, if the input system is shut down 
and subsequently warm started, all the conversations that it controls 
are lost if /START LINE is used to start the communication lines. The 
/RSTART LINE must be used to retain the previously active or held 
conversations. 


If a remote system is shut down when a conversational step is 
processing or is queued in it, and is subsequently cold started, all 
references to the conversation are lost. A conversation lost in this 
way must be specifically cancelled in the input system by the /EXIT 
command. 


Abnormal Conversation Termination 


A conversation is abnormally terminated if any one of the following 
occurs: 


e The conversational program abnormally terminates. 


e An invalid destination in the SPA, or for a conversational response, 
is reccgnized in the input systen. 


e A conversational message is inserted to a terminal whose conversation 
was terminated. 


e Destination verification fails for a conversational message. 
°® No output was generated in the application progran. 


The conversation's SPA is passed to the conversation abnormal 
termination exit routine in the input system along with an indication of 
the cause of the termination. 


NULTISYSTEN QPERATIONS 


Each system in a multisystem configuration is operationally an 
independent unit. It exclusively owns its own communication resources, 
which are controlled by its own master terminal. 


MOLTISYSTEM COMMUNICATION INITIALIZATION 


Communication between two IMS/VS systems does not begin antil the 
7RSTART LINK command is issued in each system. The normal procedure 
would be for the master terminal operator to issue this command when a 
system is started up. This procedure does not require coordination 
between master terminal operators. Communication is allowed only if the 
characteristics of the specified links are compatible. If a required 
link is not successfully started, messages will wait until the links 
have been reassigned. 
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If a system that has messages queued in it is cold started, these 
messages are lost. Since the messages that were lost can be from or to 
terminals and programs in other systems, the impact of a cold start is 
not limited to the cold started system. 


MULTISYSTEM COMMUNICATION TERMINATION 


A /PSTOP LINK command from either of two linked systems terminates 
transmission on the specified link. When transmission is terminated on 
one side, its partner in the other system terminates its own 
transmission and notifies the master terminal operator. 


LOGICAL LINK ASSIGNMENTS 


Initial logical link assignments {logical link to physical link) are 
normally made during IMS/VS system definition. The /MSASSIGN command 
can be used to dynamically make or change a logical link assignment. 
This approach is used primarily for unscheduled reassignments resulting 
from failing physical connections or systems. 


master terminal operators of the two systems must coordinate their 
assignments to a corresponding physical link. Any type of physical link 
may be replaced by any other type of physical link. 


If a restart is pending on a logical link due to physical link 
failure, both systems should use the following procedure to reestablish 
communication through an alternate physical link: 


e Reassign the logical link to the alternate physical link. 


e Use /RSTART LINK to start the logical link. 


SECURITY 


Security maintenance in a multisystem environment is performed 
independently for each system. Password security is verified on 
terminal input after execution of the terminal routing exit routine. 
Terminal security is verified on terminal input, and after an 
application program change call if the call is issued in the input 
system. 


When a destination system receives a message to process, it verifies 
security based on the input terminal's association with the logical link 
path. This prevents transactions sent by unauthorized systems from 
being processed. 


In MSC configurations, if any system uses the Resource Access Control 
Facility (RACF) then all systems must use RACF. User verification and 
transaction authorization are checked on terminal input. Transactions 
received from across a link call will be passed to the transaction 
authorization module for authorization checking, but since the password 
isn't passed across the link, transaction authorization checking fails 
if a password is required. Transactions not requiring a password can be 
accepted. Enhanced security allows the use of RACF (MVS only) or a 
user-written security exit routine for validation of the dependent 
region's authorization to use resources specified in the Application 
Group Name (AGN) table. For more information on Security provisions, 
see the chapter, ''Design and Control of a Data Base/Data Communication 
System'* in this manual, or the section ''Establish IMS/VS System 
Security (Optional) '' in the IMS/VS Installation Guide. 


5.14 IMS/VS System/Application Design Guide 


a 


RECOVERY 


Each system in the multisystem configuration uses the full recovery 
capabilities of IMS/VS. These capabilities assure that messages are 
never lost or duplicated within the single system as long as no cold 
start or emergency restart BUILDQ from an earlier checkpoint is 
performed, or no log records are lost. 


In addition, the MSC feature assures that messages are never lost or 
duplicated across a multisystem link as long as no system in the 
configuration is cold started or no log records are lost. This is 
accomplished by logging information about a transmission in both the 
sending and receiving systems. This information is restored during 
restart and exchanged between the systems once the link is started. The 
sending system can then dequeue a message that was received by the 
receiving system but for which the acknowledgment was lost due to a link 
or system failure. The sending system can also resend a message that 
was sent but never enqueued by the receiving system due to a failure in 
the receiving system. If a system in the multisystem configuration 
fails to recover, the messages for which it has recovery responsibility 
are lost. 


Since IMS/VS provides commands to dynamically change link 
assignments, an inoperable System/370 can be backed up by an alternate 
System/370. The IMS/VS system that resides in the inoperable CPU can be 
executed in the alternate CPU once all involved links are properly 
reassigned by the master terminal operators. 


COMPATIBILITY 

IMS/VS system definition has been expanded to include new macros for 
multisystem facilities. Current terminal and transaction definitions 
can be used for remote destination definitions since macro operands that 
do not apply to remote destinations are ignored in remote definitions. 
The use of Message Format Service (MFS) is the safle in a multisystem 
environment aS in a single system environment. If a message is created 
in one system for a terminal attached to another system, the required 
message and format descriptions must be available to the system to which 
the terminal is attached, and definitions with the same name must he 
defined identically in each systen. 


PERFORMANCE CONSIDERATIONS FOR MSC 

The design and tuning recommendations that apply to a single IMS/VS 
system are applicable to each IMS/VS system in a MSC environment. There 
are, however, additional considerations, related to resource consumption 
and demand, tnat must be taken into account when defining systems that 
are part of a MSC configuration. 


For IMNS/VS transactions that are processed in a local system, the 
transaction uses essentially the same hardward and software resources 
that it would in a non-MSC environment. For transactions that are 
processed in a remote system, additional resources are required. These 
resources are used to transmit the transaction over physical Links to 
the remote CPU and to receive the response back from the remote CPU. 
Performance considerations are directly related to minimizing the 
resources consumed by remote processing and balancing the resource 
demand between several CPJs in a MSC configuration. 
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MINIMIZING RESOURCE CONSUMPTION 
TO minimize resource consumption, you should: 


« Design the environment so that as many transactions as possible are 
processed locally. 


e Provide physical links that go directly from local to remote 
systems; no intermediate systems should be involved in the 
transaction routing process. Transactions that must be routed 
through intermediate systems require additional CPU activity, 
message queue activity, and logging activity. 


e Design the Message Queue Buffer Pool in each CPU to eliminate 
unnecessary Message Queue I/O activity. 


e Use CTC links, if possible, rather than BSC links; the CPU 
requirements to support a CTC link are lower per message than those 
for BSC links. 


® Define the physical link buffer sizes large enough to hold the 
message prefix plus all the segments of most messages. 


BALANCING RESOURCE DEMAND 


In a MSC environment with two or more CPUs, you should distribute the 
workload in a way that avoids excessively high utilization of any one 
CPU. You do this by distributing IMS/VS applications and their 
associated transactions and terminals between the available CPUs ina 
way that, dependent, on the complexity of the application and the 
capability of the CPU, avoids overloading each CPU. 


If the current design of the data bases is such that the data bases 
and their associated aoplications cannot be distributed across the 
available CPUs (vertical partitioning), you cans: 


e Duplicate or share inquiry-only data bases; this allows the data to 
be referenced by more than one systen. 


e Split the data bases into several component data bases (horizontal 
partitioning). The component data bases must be completely 
independent for distribution among the available CPUs. For example, 
it may be possible to divide a data base by key range intervals. 
The new data bases and their associated applications could then be 
distributed among the existing IMS/VS systems and the Terminal 
Routing Exit could be used to route incoming transactions to the 
correct IMS/VS system. Another possibility is to divide the data 
base by geographic area. Each IMS/VS system could process the 
transactions that refer to the data bases for its own geographic 
area and routs transactions that refer to a remote geographic area. 


In addition to balancing the workload across CPUs, you may also have 
to balance the workload on physical links. This occurs when a physical 
link between two systems is of the BSC type and multiple physical links 
have been installed. You can balance the workload on physical links by: 


e Specifying, during IMS/VS system definition, proper logical link 
paths and logical links for each remote application. 

e Using a user-written Terminal Routing Exit to examine the load on 
each of the alternative physical links and choose the least busy 
link for routing. 
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MSC EXAMPLES 


Figures 5-12 and 5-13 illustrate, respectively, horizontal and 


vertical partitioning. 


x 
IMS/VS System 


(San Francisco) 





Customer 
Data Base |. 
(SFO Region 
Customers) 





BSC 
Link 


Y 


IMS/VS System 
(Los Angeles) 





Customer 
Data Base 


(L.A. Region 
Customers) 





Figure 5-12. 
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CHAPTER 6. DESIGN CONSIDERATIONS FOR THE FAST PATH FEATURE 


This chapter describes the Fast Path feature and contains design 
considerations for its use. 


The Fast Path feature provides improved performance for applications 
that require large transaction rates and use only simple data 
structures. 


The Fast Path feature shares the IMS/VS Data Communication network. 
The functions of the Data Base system and the Data Communication feature 
are not reduced when the Fast Path feature is installed. The Fast Path 
feature complements the existing system and does not replace it. A 
system with the Multiple Systems Coupling (MSC) feature installed can 
also have the Fast Path feature installed; however, the Fast Path 
feature cannot receive input from the MSC intersystem links. 


The Fast Path feature provides two data base types: Main Storage 
Data Base (MSDB) and Data Entry Data Base (DEDB). 


FAST PATH DATA BASES 

The Fast Path data bases are simple in structure and provide for 
improved performance. In addition, Fast Path data bases can be accessed 
by either Fast Path or IMS/VS transactions. 


MAIN STORAGE DATA BASE (MSDB) 


An MSDB is designed for efficient processing of the most frequently 
used data in an installation. The MSDB resides in main storage, which 
reduces I/O activity. 


The amount of data that the MSDBs can hold is limited by the amount 
of available storage. 


An MSDB is a root-only data base; it has no dependent segments. Only 
fixed-length segments are allowed in an MSDB. 


There are two types of MSDBs: Terminal-related and 
Nonterminal-related. 


Terminal-related MSDBs are either fixed or dynamic. Inserts and 
deletions are not allowed ina fixed terminal-related MSDB but are 
allowed in a dynamic terminal-related MSDB. Both dynamic and fixed 
terminal-related MSDBs have the following characteristics: 


e The record can be updated only by messages issued from the LTERM 
that owns the record. However, the record can be read as a result 
of messages from any LTERM. 


e The name of the LTERM that owns a segment is the key of the segment. 
An LTERM cannot own more than one segment in any one MSDB. 


* The key does not reside in the segment. 


e Each segment in a fixed terminal-related MSDB is assigned to and 
owned by a different LTERM. 
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e A dynamic MSDB may have a pool of unassigned segments. A segment is 
assigned to an LTERM by an ISRT call and returned to the unassigned 
pool by a DLET call. 


One use for a fixed terminal-related MSDB would be in an application - 
where each segment contains data that is associated with a logical 
terminal. In this type of application it would be possible for a batch 
application program to read the segment [possibly for general reporting 
purposes), but update would be impossible. 


A dynamic terminal-related MSDB can be used as a ‘scratch pad’ area 
to simulate conversational processing not available for Fast Path 
transactions. 


Nonterminal-related MSDBs have the following characteristics: 
e There 1s no ownership of segments in a nonterminal-related MSDB. 


e No insert or delete calls are allowed against a nonterminal-related 
MSDB. 


e The key of nonterminal-related MSDB segments can be an LTERM name or 
a field in the segment. As with a terminal-related MSDB, if the key 
is an LTERM name, it doesn't reside in the segment. If the key 
isn't an LTERM name, it does reside in the sequence field of the 
segment. If the key resides in the segment, the segments must be 
loaded in key sequence because, when a qualified SSA is issued on 
the key field, a binary search is initiated. 


The nonterminal-related MSDB without terminal-related keys would be 
used in any application where a large number of people need access to 
and update capability for data ina high transaction rate situation, for 
example, a real time inventory control application, where reduction of 
inventory could be noted from many cash registers. = 


An MSDB is defined with DBDGEN in the same way as any other IMS/VS 
data base. The data base is specified as an MSDB by coding ACCESS=MSDB 
in the DBD statement. The REL keyword in the DATA SET statement is used 
to select one of four MSDG types: 


e Terminal-related dynamic 

®e Terminal-related fixed 

e Nonterminal-related with LTERM keys 

e Nonterminal-related without LTERM keys 


The definition of an MSDB data base is covered fully in the IMS/VS 
Utilities Reference Manual. 


MSDB DLZI Calls 


All DL/I data base calls, except those that specify "within parent," 
are valid with one or more types of MSDBs. Because an MSDB is a 
root-only data base, a “within parent" call is meaningless. 
Additionally, there is a DL/I call, FLD, applicable to all MSDBs. The 
FLD call allows an application program to check and modify a single 
field within an MSDB segment. ) 
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The FLD Call 


The FLD DL/I call is unique to Fast Path. It allows for the 
operation on a field rather than on an entire segment. Additionally, it 
allows conditional operation on a field. 


Modification is done with the CHANGE form of the FLD call. The value 
of a field can be tested with the VERIFY form of the FLD call. These 
forms of the call allow the application program to test a field value 
before applying the change. If a VERIFY fails, all CHANGE requests in 
the same FLD call are denied. This call is described fully in the 


Allowable processing options for MSDB types are? shown below: 


Non-related=-===+2+=<<<<=--= G,R 
Related fixed------------- G,R 
Related dynamic----------- G,l,R,D,A 


The following chart shows relationships between MSDB calls, MSDB 
types and call qualifications. Numbers refer to notes below. X 
indicates an allowable combination. 


] DB TYPE | CALL QUALIFICATION | 
Grr tes ae eee Se ee ee a cea nee age ee et eee eee a | 
} DL/I | Min !Non{ Rel] Rel! | | | 
} Call | PROCOPT|/rel|f£ix|dyn|No SSA|{Unq.SSA{Qual.SSA| 
lenient gaan beeelecs lee lereees jereeos lets 
} GU | G }; X |} X | KI xX | x ! Xx ! 
lanenag ea eecs las ore ae wae (oeees liars 
{ GHN |G | xX | KX | X¥ | X | x | x | 
lee ecan [22Sec== Fags (aaeia ove leet aan aes eee | 
} GN | G i xXx j{xt xi xX X | X | 
[Aeesee pesos gees eee) aie lcci [iste <2= pereeecie> 
1! GHU | G ' x jx { x] xX | x { X | 
lepeendy (Sees eae eee loea ees enreces ona 
] REPL | R } XK | XJ Xf! X ! Xx 2 ] xX 2 | 
maeee eeeeais Nee aera eral ergs ageeeaes a eeremeaae ! 
| FLD | G/R 14K t X | XJ Xx | X | X ! 
[==--3= ate es eee oe see esse ees 
} ISRT | £ 1 | xX | | x i x 3 | 
lawaels [sesnsss (eee lens nesses leases omens | 
| DLET | D | | 1X | Xx | xX 2 | KX 2 | 
Le werwre oe we ewe ewe wee ewe ee oe fe 7 oe ewe oe ew 2 ewe © eee sw oe ew oe m 
Notes: 


1. R required for change. 
2e Combination allowed, SSA ignored. 


3. Qualification ignored but seqment name is used. 


MSDB Buffer Allocation 


Fast Path data base buffers are allocated when a call to update an 
MSDB record is issued by an application program, a verify call, or if 
hexadecimal translation is required. The buffers hold the update 
information until a synchronization point is reached. The maximnun 
number of buffers that the application program can use is dependent on 
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the number of normal page-fixed buffers (NBA) and the number of 
additional page-fixed buffers (OBA) specified in the EXEC PARM field. 


DATA ENTRY DATA BASE [DEDB) 


A Data Entry Data Base (DEDB) is a hierarchical data base containing 
a maximum Of eight segment types (a root segment, an optional sequential 
dependent segment, and zero to seven direct dependent segments). If the 
Optional sequential dependent segment type is defined, a maximum of six 
direct dependent segment types can be defined. Sequential dependent 
segments are stored in chronological order, regardless of the root on 
which they are dependent. Direct dependent segments are stored in 
hierarchical fashion, allowing for rapid retrieval. 


The DEDB is designed to: 

e Collect or gather detailed information. 
e Enhance data base availability. 

e Retrieve and update summary information. 


The physical format of the data base enhances the availability of the 
data. Ina traditional IMS/VS data base, the logical data structure is 
spread across the entire data base, or if multiple data sets are used, 
the data structure is broken up on a segment basis. A DEDB may use 
multiple data sets, called areas, with each area containing the entire 
data structure, as illustrated in Figure 6-1. A DEDB record {a root and 
its dependent segments) does not span areas. A DEDB can be divided into 
as many as 240 such areas. This organization is transparent to the 
application program. The randomizing module is used to determine what 
records go to what area. 


Initialization, reorganization, and recovery is done on an area 
basis. Resource allocation is done at the Control Interval (CI) level 
so that multiple programs or online utilities can concurrently access an 
area within a data base, providing they are using different CIs. 


Each area in a DEDB is a VSAM data set. An area is opened by the 
first call to it from a program that is eligible to access it. A single 
area in a DEDB can be stopped by the operator with the /STOP AREA 
command. A DEDB can be stopped with the /STOP DATABASE command. These 
commands do not affect programs that are currently scheduled against the 
DEDB. The /STOP DATABASE command does prevent the scheduling of any new 
programs needing access to the stopped data base. When a write error is 
detected in an area, that specific area is stopped and the application 
program receives an FH status code. Even though a part of a data base 
may not be available (one or more areas are stopped), the data base is 
Still logically available and transactions using that data base are 
still scheduled. 
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Figure 6-1. 
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A DEDB area is divided into three parts: 


® Root addressable, 


e Independent overflow, 


and 


e Seguential dependent part 
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DEDB Area 


Figure 6-2. DEDB Area Division 


Figure 6-3 shows how the DEDB is further divided into units-of-work 
{UOW) in the root addressable part of the area. 


DEDB 





Area 1 Area 2 Area 3 


A DEDB may contain a maximum of 10 Areas 


Figure 6-3. DEDB Units-of-Work 


Root Addressable Part 


The root addressable part of an area is the only part that is 
actually divided into units-of-work (UOW), as shown in Figure 6-3. A 
YOW consists of a user-specified number of contiguous control intervals. 
Each UOW is further divided into a base section and an overflow section. 
The base section contains CIs that are addressed by the randomizing 
routine. The overflow section contains logical extensions of any CI in 
the UOW. 


The independent overflow part contains empty control intervals that 
can be used by any UOW in the area. Once a UOW obtains a control 
interval from the independent overflow part, the control interval can 
only be used by that UOW. A control interval in the independent 
overflow part can be considered an extension of the overflow section in 
the root addressable part as soon as it is allocated to a NOW. The 
independent overflow CI remains allocated to a specific UOW unless, 
after a reorganization, it is no longer required at which time it is 
freed. 
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Sequential] Dependent Part 


The sequential dependent part holds sequential dependent segments 
from roots in all units-of-work in the area (see Figure 6-4). The 
sequential dependent segments are stored in chronological order without 
regard to the root or unit-of-work that contains the root. When the 
sequential dependent part is full, it is reused from the beginning. 
However, before the sequential dependent part can be reused, the user 
must use the DEDB utility DBFUMDLO to delete a contiguous portion, or 
all, of the sequential dependent segments in the sequential dependent 
part. 








Units of Work 
Independent Sequential 
Overflow Dependent 
Base Part 
Section 
Root Addressable Part 
DEDB Area 
Figure 6-4. Storage of DEDB Dependent Segments in an Area 


Space Definition 


You can specify the size of the UOW, the base section, the overflow 
section, and the number of UOWs in the root addressable part and in the 
independent overflow part. This gives flexibility in controlling 
resource and space management. Each area in a DEDB has its own space 
management parameters. These parameters may be chosen according to the 
message volume that can vary from area to area. 


Root segments in a DEDB have, and direct dependents may have, a 
Single key field. They can be accessed direcly by this key. The 
sequential dependent segments can have scan fields by which they can be 
identified in a sequential scan. Scan fields do not have to be unique. 
Because the sequential dependent segments are stored in a time-of-entry 
sequence, there is no guarantee that they will be maintained in scan 
field sequence. All segments in a DEDB are variable in length and the 
length may be changed with a REPL call. 


Access to a DEDB is by a subset of DL/I calls that are compatible 
with the standard IMS/VS DL/I calls. Get, replace, delete, and insert 
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calls are provided for root and direct dependent segments. Get and 
insert are the only calls allowed against a sequential dependent 
segment. 


DEDB root segments are stored as prescribed by the randomizing 
routine, chained in order of ascending key from each anchor point. Each 
control interval in the base section of a UOW within an area has a 
single anchor point. Sequential processing using Get Next calls will 
process the roots in order of: 


1. Ascending area number 
2 Ascending UJOW 


3. Ascending key within each anchor point chain 


Sequential Dependent Segment Processing 
DEDB sequential dependents are stored in the sequential dependent 

part of an area in the order of entry. Sequential dependents chained 

from different roots within an area are intermixed in the sequential 

part of an area without regard to which roots are their parents. 

Sequential dependents have been specifically designed with a fast insert 

capability. However, online retrieval will not be as efficient because 

increased input operations might result. If all the sequential 

dependents were chained from a single root segment, processing with Get 

Next Within Parent calls would result in a backward sequential order. 

(Some applications may be able to use this method.) Normally, sequential 

dependent segments are retrieved sequentially only by using the 

sequential dependent scan utility which is described in the IMS/VS , 

Utilities Reference Manual. They are then processed by offline jobs. 


Direct Dependent Seqment Processing 

The DEDB maintains processing efficiency while supporting a 
hierarchic physical structure with direct dependent segment types. A 
maximum Of seven direct dependent segment types are supported (only six 
if a sequential dependent segment is present). 


Direct dependent segment types can be efficiently retrieved 
hierarchically and the user has complete online processing control over 
the segments. Supported processing options are insert, get, delete, and 
replace. The length of the segment can be altered by the user using the 
replace function. The DEDB space management logic attempts to store an 
inserted direct dependent in the same control interval that contains its 
root segment. If sufficient space is not available in that CI, the Root 
Addressable Overflow and then the Independent Overflow portion of the 
Area are searched. 


Physical chaining of direct dependent segments consists of a Physical 
Child First Pointer in the root for each defined dependent segment type 
and a Physical Twin Forward pointer in each dependent segment. 


DEDB Synchronization Processing 

The physical update of a DEDB root and direct dependents is held in 
abeyance until a synchronization point has been reached and 
synchronization processing is completed successfully. This sequence 
eliminates the need for backout processing in case of a user program 
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failure. DEDBs are physically updated after the associated log records 
are written. 


DEDB sequential dependent segments are gathered at synchronization 
processing time but are not written to the physical data base until a 
control interval is filled. Logging takes place during synchronization 
processing, and changes are discarded if a failure occurs. 


A DEDB is defined through the DBDGEN process as are all other IMS 
data bases. To specify that a data base is to be a DEDB, ACCESS=DEDB is 
specified in the DBD statement. Further information on generating a 
DEDB is contained in the IMS/VS Utilities Reference Manual. 


Prior to the initialization of DEDB areas, the areas (data sets) must 
be defined via VSAM Access Method Services. Following is an example of 
Access Method Services input that defines a VSAM cluster which will 
later be defined in a DBDGEN as an area with the name of AREA1: 


DEFINE - 

CLUSTER- 
(NAME(AREA1) - 
VOLUMES (SFR123) - 
NONINDEXED - 
CYLINDERS {1) - 
CONTROLINTERVALSIZE (1024) - 
RECORDSIZE(1017) - 
SPEED) - 

DATA - 


(NAME(DATA1)) - 
CATALOG (USERCATLG) 


The following keywords have special significance when defining a DEDB 
area: 


e NAME: The name supplied for the cluster is the name subsequently 
referred to as the areaname. The name for data component is 
optional. 

e NONINDEXED: DEDB areas are not indexed clusters. 


® CONTROLINTERVALSIZE: The value supplied must be 512, 1024, 2048, or 
4096 bytes due to a VSAM ICIP requirement. 


e RECORDSIZE: The record size is always seven less than the control 
interval size. These seven bytes are used for VSAM control 
information at the end of each control interval (see "DEDB DBD Space 
Considerations"). 

e SPEED: This keyword is recommended for performance reasons. 


e CATALOG: This parameter may be optionally used to specify a user 
catalog. 
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DEDB DBD SPACE CONSIDERATIONS 


When designing a DEDB, attention must be paid to ensure that 
sufficient space is allocated in all parts of the area. To do this, the 
designer must know how much space is available in each control interval 
for data and how much space is used for Fast Path and VSAM control 
fields. Fast Path control fields consist of both control-interval 
control fields and SEGM control fields (segment prefixes). 


The following figures illustrate control interval and segment 
formats. 


' 1 
} FSE | CI {| RAP | SEGMENTS and FSEs | RBA t RDF |[ CIDF | 
} AP | TYP | | | ! | | 
Lew © @ 0 oe ow ww ww ow ww ww www ww 0 ww ww ow www ow ww wr ww ww ow ww www ww ww ww ow we we owe Jj 
FSEAP 2 bytes Offset to the first Free Space Element. These two 


bytes are unused if the CI is in the Sequential 
Dependent Part. 


CITYP 2 bytes Describe the use of this CI and the meaning of the 
four next bytes. 


RAP 4 bytes Root Anchor Point if this CI belongs to the Base 
Section of the Root Addressable Area. All Root 
segments randomizing to this CI will be chained off 
this RAP in ascending key sequence. There is only 
one RAP per CI. 


Note: In the Dependent and Independent Overflow 
Parts, these 4 bytes are used by FP for control 
information. There is no RAP in Sequential 
Dependent CIs. 


RBA 4 bytes RBA of this CI 
RDF 3 bytes Record Definition Field (VSAM Control Information) 
CIDF 4 bytes CI Definition Field (VSAM Control Information) 


Note: CI control field length in Root and Overflow parts: 19 bytes CI 
control field length in Sequential Dependent part: 15 bytes 


Figure 6-5. Control Interval Format 
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_ 
1S} P {| PTF | SPCF | PCF | { PCF] LL ! DATA ! 
|; Cc] Dt} PTR { PTR Jf PTR | | PTR 
eT pee ere ee ase pe er ee etiam ie ey a aaa a a aa Ee ho dl 7 
| 1 1 4 8 4 Gq | 

| | 

SEGMENT 

| R= 22 no oo ne oo 2 ee >] 

PREFIX 

SC 1 byte Segment Code: 01 

PD 1 byte Prefix Descriptor 

PTF 4 bytes Physical Twin Forward Pointer. Contains RBA of the 
next root in key sequence. 

SPCF 8 bytes Sequential Physical Child First Pointer. Contains 
RBA of the last inserted sequential dependent under 
this root. This pointer will not exist if the 
sequential dependent segment is not defined. 

PCF 4 bytes Physical Child First Pointer. Points to the first 
occurrence of a direct dependent segment type. 
There can be up to 6 PCF pointers or 7 if there is 
no sequential dependent segment. This pointer will 
not exist 1f direct dependent segments are not 
defined. 

LL 2 bytes Variable Length of this segment. 

Figure 6-6. Root Segment Format {with sequential and direct dependent 

segments) 

Gre ee ee Se ee ae as AE ian sai ca ca ee a 1 

t S | U {| SPTF [| LL J DATA | 

} Cc | N | PTF | | | 

Leo ewe 0 we ww 0 ww oe wo wee 2 ow ww ww ow ow eww ow ooo ew wow oo Jf we rewe wow oe ewes eee eo oe woe aod 

; 1 1 8 { 

| 
! SEGMENT 
| <-+----------- >| 
PREFIX 

sc 1 byte Segment Codes 02 

UN 1 byte Unused 

SPTF 8 bytes Sequential Physical Twin Forward Pointer. Contains 
RBA of the immediately preceding sequential 
dependent segment under the same root. 

LL 2 hytes Variable length of this segment. 

Figure 6-7. Sequential Dependent Segment Format 
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Ge ee eit aie ae een ee ee ee ae ff Fe VHA Fea Ss ae ee ae eee ae 1 
ij S { U0 | PTF { LL | DATA | 
1C | N | PTR I | 1 3 
Pe yer et Gee ere epee ete ee re eon ae te ey ee a GS Pe eae a ee a re id ) 
' 1 1 4 { 
| 
} SEGMENT 
PREFIX 

sc 1 byte Segment Code 
UN 1 byte Unused 
SPTF 4 bytes Physical Twin Forward Pointer. Contains RBA of the 

next occurrence of this direct dependent segment 

type. 
LL 2 bytes Variable length of this segment. 
Figure 6-8. Direct Dependent Seqment Format 
Example 


Assume that all root segments in an area will be 200 bytes in length 
(198 bytes of segment data plus 2 bytes for the length field) and that 
there will be 850 root segments in the area. There are sequential 
dependents defined. The control interval length is 1024. There will be 
200 sequential dependent segments inserted. Each sequential dependent 
segment is 150 bytes long (148 bytes of data and a 2-byte length field). 
There is one direct dependent segment type defined with an average 
length of 20 bytes [18 data and 2 bytes length field). The expected ) 
frequency of occurrence is one direct dependent per root segment. 


Calculate the minimum space reguired to hold root segments: 


1024 Control interval length 
- 19 Minus control-interval control fields 
1005 Equals the amount of space for root 


segments and their prefixes. 


The space required by the root segment 
and its prefix is 218 bytes and for the 
direct dependent and its prefix is 

26 bytes. Total space with single 
occurrence of the direct dependent is 
244 bytes. 


1005 -, 244 = &,1 The amount of root, direct dependent, 
and prefix space divided by the total 
length required by a root and its 
direct dependent equals the number of 
roots that are likely to fit in one 
control interval. Because DEDB segments 
do not span control intervals, the DEDB 
area will hold four roots per control 
interval. 
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850 / & = 212.5 The minimum amount of space to hold the 
defined number of roots with their 
expected direct dependent segments to 
be inserted into this area (850) would 
then be 213 control intervals. 


Calculate the minimum space required to hold the sequential dependent 
segments: 


1024 Control interval length 
- 15 Minus control-interval control fields 
~ 7009 Equals the amount of space for sequential 


dependent segments and their prefixes. 


1009 / 160 = 6.3 The amount of sequential dependent and 
prefix space divided by length of one 
sequential dependent segment and its prefix 
equals the number of segments that will 
fit in one control interval. Because 
DEDB segments do not span control 
intervals, this DEDB area will hold 
six (6) sequential dependent segments 
per control interval. 


200 / 6 = 33.3 The minimum amount of space required to 
hold the defined number of sequential 
dependents to be inserted into this 
area (200) would then be 34 control 
intervals. 


The minimum amount of space that must be allocated for this area is 
247 control intervals (213 for roots and 34 for sequential dependent 
segments). 


Performance Considerations in Loading a 


DEDB Area 


Performance can be significantly improved if the segments to be 
inserted are first processed through the randomizing module -- without 
actually loading the DEDB area -- and the address of the selected area 
and anchor point for each segment noted. (See the System Programming 
Reference Manual for a complete discussion on the output from the Fast 
Path data base randomizing module.) The input segments should then be 
sorted into ascending sequence based upon the area and anchor point 
obtained from the randomizing module. 


For example, if segments S1, $2, S3, and S4 will be randomized by 
area and anchor point to the sequence S2, S4&, S1, and S3, it would be 
advantageous to place the input segments into this order prior to 
actually loading the DEDB area. If direct dependent segments are also 
to be loaded, they should be sorted to follow the root segment in 
appropriate order. By presorting the input segments, the insertions 
will be processed in a physical sequential manner and will result in 
accessing and filling each control interval only once during the loading 
process. When a program that has specified PROCOPT=P, attempts to cross 
a unit-of-work boundary, the GC status code is obtained. It is 
recommended that a SYNC call is made to commit the inserts to ¢he DEDB. 
Use of the PCB option PROCOP=P will hold positioning for subsequent 
insertions across synchronization point processing. If the segments are 
not sorted to correspond to the output of the randomizing module, the 
control interval will have to be accessed for each insertion of a 
segment into the control interval. This will result in significant 
overhead during the DEDB loading process. 
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DEDB Data Base Full Condition 


the sequential dependent portion or one unit of work in the root 
addressable portion of that area can no longer accept ISRT calls. 
System and user responses to the condition vary according to which 
portion is filled and what type of region issued the ISRT call. 


The ‘data base full' condition ina DEDB area indicates that either 


The out of space condition for sequential dependents is originally 
detected at synchronization point processing. If there is not 
sufficient space for the insert, all updates that occurred during that 
sync interval are discarded. If the ISRT call was issued from a Fast 
Path non-message driven or a BMP region, an 'FS* status code is returned 
to the caller. If the call was from either a Fast Path message driven 
Or an MPP region, the input message is rescheduled for execution. All 
subsequent calls to insert a sequential dependent to that area 
(including the rescheduled transaction that originally detected the out 
of espace condition) will receive an 'FPS' status code at call time. 


Out of. space in the root addressable portion of the area is indicated 
to the user in one of two ways. If the ISRT was issued from a Fast Path 
non-message driven or a BMP region, an ‘'FS' status code is returned at 
call time. If the ISRT was issued from a Fast Path message driven or 
from an MPP region, the region will be abnormally terminated with a user 
844 abend code. 


There are two techniques Fast Path allows the user to monitor space 
utilization within a DEDB Area. The 'POS* call can be used to track the 
sequential dependent portion of the area while the /DISPLAY DATABASE 
Operator command will show the total allocated and the total used 
control intervals in both the root addressable and the sequential 
dependent portions of the area. 


If the DEDB Area does reach the data base full condition, Fast Path E 
provides two online utilities which may negate the need for doing a data 
base unload/reload offline to resolve the problem. One of the online 
utilities, the Sequential Dependent Delete utility, will delete the 
sequential dependent segments in all or part of the sequential dependent 
portion of the area and thus make this space available for sequential 
dependent inserts. The other online utility, the Direct Reorganization 
utility is run against one DEDB Area at a time and is used to remove 
space fragmentation within that area. Although the reorganization can 
be limited to the one unit of work which did not allow inserts, it may 
be advisable to reorganize more or all of the area as any independent 
overflow space that is freed from one unit of work becomes available for 
use by any other unit of work within that area. 


FAST PATH PROGRAM TYPES 


A Fast Path application program executes in a Fast Path IFP region. 
The IFPs are handled differently depending on the type of program that 
is running in the region. There are three uses for the regions in which 
Fast Path processing is done: 


e Applications for processing Fast Path messages 
e Applications for processing input external to Fast Path 
e Utilities initiated against the data bases 
Regions executing message-initiated applications operate in a 
wait-for-input mode. Both, message-driven and nonmessage-driven 2 


application programs executing in an IFP region, can access and update 
MSDBs, DEDBs, and IMS/VS online data bases. Nonmessage-driven 
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application programs can also access OS/VS data sets through OS/VS data 
Management. 


Regions executing online data base utilities execute concurrently 
with Fast Path processing. This region type is similar to a 
nonmessage-driven application program but no user-written application 
program is needed. 


Message-driven application programs cannot terminate normally unless 
a QC status code is posted in the I/O PCB. Nonmessage-driven 
application programs cannot terminate normally without releasing the 
buffers. A SYNC or ROLB call must be issued to release the buffers. 


MESSAGE HANDLING 


With the Fast Path feature installed, all Fast Path exclusive or Fast 
Path potential transactions are directed to a Fast Path routine, with a 
user exit routine, that determines if the transaction is for Fast Path 
or IMS/VS. 


Messages from a non-Fast Path eligible terminal are routed directly 
to IMS processing without resorting to the user exit routines. Messages 
from Fast Path terminals that meet the Fast Path criteria defined by the 
user exit routine are routed to the Fast Path message handling routines. 


Fast Path input and output messages can only be a single segment and 
must not exceed a fixed maximum length. 


The Fast Path online application programs operate in a wait~for-input 
mode, and must be prescheduled before a transaction can be entered 
through Fast Path terminals. Parallel scheduling is supported through 
IMS/VS system definition. 


INPUT MESSAGES 


Fast Path input messages are limited to a single segment. Every Fast 
Path transaction is defined to the system as a Fast Path potential or 
Fast Path exclusive transaction. Potential transactions can be executed 
under IMS/VS processing or Fast Path processing. A user-written exit is 
required to analyze the input message to determine if it should be 
routed to IMS/VS or Fast Path. 


A Fast Path exclusive transaction can only be processed by a Fast 
Path application progran. 


All input messages that are to be processed under Fast Path must he 
issued from a Fast Path eligible terminal. A Fast Path potential 
transaction that is to be processed by IMS/VS can be issued from a 
terminal that is not Fast Path eligible. 


OUTPUT MESSAGES 


Fast Path output messages are limited to a single segment. Only one 
insert call can be issued against the PCB. The output segment cannot 
exceed a prespecified maximum segment length defined at systen 
generation. 


The output message and the input message are not logged until a Get 
Unique is issued to the PCB to obtain the next input message. If a 
failure occurs before this synchronization point is reached, both the 
input and output messages are lost. 
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SYNCHRONIZATION POINT PROCESSING 

The sync process is structured into phases. During phase 1, required 
resources are obtained and log records are created. Obtaining only the 
resources reguired by this sync process allows this sync process to 
execute in parallel with other sync processes. After phase 1 there is a 
transition portion during which the log records are passed to the 
logical logger. After transition, phase 2 continues the necessary 
updating, and then a cleanup portion of phase 2 releases resources and 
cleans up control blocks. 


Synchronization point processing is performed after a message Get 
Unigue call, a SYNC call, or CHKP call from an application program. The 
philosophy of Fast Path processing is to hold all application program 
updates in main storage until a synchronization point is reached. All 
logging on the IMS/VS log tape is performed during synchronization point 
processing but before the application of data base updates. 


If the application program uses the verify function in MSDB calis, 
the verify will be re-executed during synchronization point processing. 


If the conditions are met, the synchronization point processing 
completes as expected. If the conditions are not met, the 
synchronization point processing purges all update information and gives 
the same input message to the application for reprocessing. 


FAST PATH AND IMS/VS INTERRELATIONSHI 


Fast Path application programs can retrieve from, as well as update 
all DL/I data bases available to IMS/VS online application programs. 
Fast Path applications can use all facilities associated with alternate 
PCBs to route messages to any terminal, as well as to IMS/VS 
transactions. The routing of messages to terminals and transactions can 
be either local or remote if the MSC feature is co-resident. All cails 
directed to the I/O PCB or response alternate PCB by Fast Path 
applications are processed by Fast Path. All DL/I calls that are not 
directed to a specific PCB are passed to IMS/VS for analysis and 
processing. 


All IMS/VS online applications can retrieve from, as well as update 
all Fast Path data bases. Only DL/I calls directed to a DEDB or MSDB 
PCB are processed by IMS/VS/FP; all other calls are processed by IMS/VS. 
The use of the alternate PCB to send a message to a Fast Path 
transaction from an IMS/VS transaction is prohibited. Any attempt to 
use a CHNG call to set the destination of a modifiable alternate PCB for 
a Fast Path exclusive transaction results in an Al status code. An ISRT 
call on a non-modifiable alternate PCB with a Fast Path exclusive 
transaction as destination results in a QH status code. Any attempt to 
message-switch to a Fast Path potential transaction results in the 
routing of the message to the IMS/VS application program without going 
through the IMS/VS/FP input Editing/Routing exit routine. 
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transmission block, IMS/VS load balancing, message scheduling 2.11 
processing of 2.69 loading a DEDB area 6.13 
transmission code modes 2.68 loading a HDAM data base 4.37 
conversational processing eo9 local system 5.3 
destinations, presetting of 2.59 local transaction, MSC 5.7 
interface, purpose 2.59 log tape, restarting IMS/VS 2.28 
operating modes, Systen/s3, logging, dual 2.28 
Systen/7 2.63 logical child -- logical delete, example 
ask-tyre operating mode 2.63, 2.67 of 4.82, 4.83 
basic operating mode 2.63 logical child -- physical delete, of 4.81 
combining modes 2.63 logical child -- physical/logical delete, 
non-ask-type operating mode 2.66 example of 4,83 
system definition 2.62 logical child -- virtual delete, exanple 
ASK message 2.63 of 4.85 
ask-type station, defining 2.62 logical child insertion 4.71 
operating modes, definition of 2.63 logical child/logical twin pointers 4.61 
output transmission code modes, logical child segment 4.54 
Systen/7 2.63 logical child segment, access paths 4.77 
postpone output flag 2.63 logical child, delete rules for 4.80 
postpone type station, logical child, rules for defining 4.62 
defining 2.63 logical data base 4,104 
transmission limit, defining 2.63 defining 4.104 
unlimited transmission, illustration 4,107 
indicating 2.63 rules for 4.107 
system messages, IMS/VS definition 4.104 
message number, use of 2.61 logical relationships, crossing 4.104 
Systean/3, Systeu/7 example 4.108 
requirements 2.60, 2.61 first and additional crossed 4.104 
transmission blocks illustration 4&.106, 4.107 7 
block identifier 2.59 logical destinations, MSC 5.7 ; 


data type, description of 2.59 
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logical insert rule 4.71 
example of 4.73 
logical link numbers 5.5 
logical link, MSC 5.5, 5.6 
logical link path 5.5 
logical parent -- logical delete, example 
of 4.89, 4.90 
logical parent -- physical delete, 
example of 4.87 
logical parent -- virtual delete, example 
of 4,90 
logical parent pointer 4.61 
logical parent segment counter 4.61 
logical parent, delete rules for 4.79 
logical parent, rules fcr defining 4.62 
logical/physical relationships, 
changing 2.50 
logical record formats, HISAM data 
base 4.24 
logical record length distribution 4.156 
logical record lengths, HISAM data 
base 4.24 
logical records, HISAM structure 
Of 4.23, 4.24 
logical relationship paths 4,53 
logical relationships 4.48 
defined in, possible data sets 4.59 
defining data base sequence 
fields 4.61 
description of 4,48 
logical child segment 4.54 
pointers and the counter used in 4.59 
counter 4.61 
logical child/logical twin 
pointers 4,59 
legical parent pointer 4.60 
physical parent pcinters 4,59 
relationship paths 4,53 
segment types, relating through a 
logical child 4.48 
method one 4,50 
method two 4.51 
terms used to descrikte 4,48 
types of 
physically paired 
bidirectional 4.49 
unidirectional 4.49 
virtually paired bidirectional 4.49 
use, reason for 4.48 
logical replace rule 4.66 
example 4.68 
logical terminal class 2.46 
logical terminal/physical terminal 
relationship 
diagram 2.50 
multiple users 2.49 
nonswitched network 2.49 
one user 2.49 
switched network 
diagram 2.51 
IAM command (IMS/VS) 2.52 
inguiry logical terminal, the 2.52 
icgical terminal subpools 2.52 
Sign on 2.52 
system definition, IMS/VS 2.50 


logical terminal pool 2.52 
logical terminal subpool 2.52 
use of 2.53 
logical terminals 
concept, definition of 2.46 
IMS/VS logical terminal 
attributes of 2.47 
device class sensitive terminal 
I/O, separating 2.49 
input/output 2.47 
physical terminals, input 
relationship to 2.47 
physical terminals, output 
relationship to 2.47 
network design 2.48 
application class 2.49 
logical terminal class 2.49 
security considerations 2.47, 2.48 


Main storage data base 6.1 
buffers 6.3 
defining 6.2 
description 6.1 
DL/I calls 6.2 
dynamic 6.2 
nonterminal 6.2 
processing options 6,3 
types 6,1 
Maintenance exit routine, secondary 
index 4,118 
maintenance processing, secondary 
indexes 4,118 
masks, output 3.24 
mass storage system (MSS) 2.81 
master terminal 
devices allowed as 2.54 
inoperable, backup when 2.54 
operator, defining security for 2.73 
physical location 2.54 
3270 2.57 
message 3, 13-3.19 
definition of 2.12, 2.13 
message class 2.10 
message-driven BMP 2.29 
message editing 
edit routine, locaticn of 3,24 
control region 3.24 
control region, IMS/VS 3.24 
link pack 3.24 
message processing region 3.24 
purpose 3.23, 3.24 
message editor 2.55 
message format service 2.54 
message identifier 2.59 
message input descriptor (MID) 2.55 
message output descriptor (MOD) 2.55 
message processing region 
initiating 2.2 
performance for modules preloaded 2,4 
message queues 
emergency restart repositioning 
MULT mode processing, when in 2.42 
SNGL mode processing, when in 2,42 
index 2.35, 2.41 
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logical terminal, for 2.32 
operation of 2.41 
system failure, with 2.42 


queue data sets 
block size 2.33 
destroyed, if 2.34 
preformatted 2.34 
relationship between 2.33 

queue recoverability 2.34 

queue storage 2.34 

reuse of 2.34 

structure of 2.33 


transaction code, for 2.32 


message routing, MSC 5.6 
message scheduling 


algorithm 2.10 
application program atnormal 
termination 2.23 
deadlock situations 
effects on system 
performance 2.24, 2.25 
program isolation, operation 
of 2.24, 2.25 
synchrenization point, program 
isolation 2.24, 2.25 
contention for resources 
control block buffer pools 
excessive loading, systen 
performance effects of 2.25, 2.26 
size requirements 2.25, 2.26 
conversational attribute 
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2.25, 2.26 


effects on system performance 2.17 
performance, enhancing 2.17 

data base processing intent 2.18, 2.19 
intent levels 2.19 
intent list 2.19 

load balancing 
definition of 2.11 

message class and region class, 

by 2.10 

conflict resolution 2.11 
message selection process 2.10 


scheduling options 2.10 
multifle/single segment messages 
end-of-data (EOD) 2.12 


end-of-message (EOM) 2.13 
end-of-segment [EOS) 2.13 
example 2.13 

primary concerns when 
selecting 2.14 


non-update transaction processing 
definition of 2.17 

output limits, application progran 
results of 2.12 
use of 2.12 

processing intent specifications 
exclusive 2.21 
intent types 2.20, 
opticns 2.22 
read only 2.21 
update 2.21 

processing limits 
linit count, use of 2.12 

response and non-response messages 
recommendation 2.17 
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scheduling concurrency, factors 
effecting 2.21 
delete option 2.23 
get option 2.22 
insert option 2.22 
replace option 2.22 
selection priorities 
explanation of 2.11 
limit priority 2.11 
normal priority 2.11 
zero priority, assigning 
terminal response mode 
definition 2.15 
line performance, 
options 2.16 
message scheduling algorithm 
definition of 2.9 
influences on, design 2.9 
message scheduling, definition 2.9 
message segment format 3.15 
message segments 
definition of 2.13 
message Fast Path 6.15 
modes of response 3.17 
modifications, data base 
logging of 1.3 
module preload function 2.3 
monitor, IMS/VS DB 
activation/deactivation of 
description of 1.21 
function of 1.21 
recommendations for use 
collecting data, for 1.21 
testing application, for 
tuning system, for 1.21 
monitor, IMS/VS DC 
description of 2.78 
function of 2.78 
recommendations for use 
collecting data 2.78 
integrating applications, effects 
of 2.78, 2.79 
testing applications 
tuning system 2.78 
“7MSASSIGN command 5.5, 5.14 
MSC feature (see multiple systems coupling 
(MSC) feature) 
MSIINK macro 5.5 
MSNAME macro 5.6 
MSDB 6.1 
MSS 2.81 
MIM link 5.4 
multiline multipoint (MLMP) feature, 
System/3 2.79 
multiple data set group segmentation, 
HISAM 4,139 
muitiple data set group, HISAM data 
base 4,34 
multiple data set groups, HISA*S 
multiple data sets, DEDB 6.4 
multiple systems coupling (MSC) 
feature 5.1 
communication initialization, 
multisystem 5.13 
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effects on 2.15 
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1,21 


2.78 


4.132 


J 


C communication termination, 
multisystem 5.14 
compatibility 5.15 
conversation termination 5, 12 
abnormal 5.13 
normal 5.12 
conversational processing 5.11 
description of 5.11, §&.12 
scratchpad areas (SPAs) 5.11 
description cf 5.1, 5.3 
design considerations 5.15, 5. 16 
overhead, minimizing 5.16 
werkload, balancing 5.16 
destination system 5.8, 5.9 
destination terminal 5.8, 5.9 
stopped transactions 5.9 
destination verification 5. 10-5.12 
examples 5.17, 5.18 
Fast Path feature 6.1 
horizontal partitioning 5.1, 5.10, 5.17 
input system 5.7, 5.8 
input terminal 5.8 
intermediate system 5.9 
link security 2.73 
(see also terminal security) 
links 5.7 
logical link 5.5-5.7 
assignments 5.14 
partners 5.5 
remote logical terminals 5.5 
physical link 5.4 
types of 5.4 
‘Ges local destination 5.7 
local system 5.3 
local transaction 5.7 
logical destinations 5.7 
local 5.7 
remote 5.7 
logical length path 5.7 
message routing 5.6 
multiple systems verification 
utility 5.7 
overhead, minimizing 5. 16 
physical link 5.4 
recovery capabilities §&.15 
remote destination 5.7 
remote logical terminals 5.5 
remote systems 5.3 
remote transactions 5.7 
priorities 5.9 
routing exit routines 5.10, 5.11 
program routing §&.10 
terminal routing 5.10 
routing path 5.6 
security maintenance 5,14 
system identification 5.6 
examples of 5.6, 5.7 
vertical partitioning 5.1, 5.16, 5.18 
workload, balancing 5.16 
multiple systems verification utility 5.7 
multipoint line, definition 2.44 
multisegment and single segment messages 


message scheduling 3.15 
( multisystem envircnment 5.1, 5.3, 5.7 


NAME macros 5.5 
names, logical terminal 2.53 
naming conventions 
advantages of 3.4 
dictionary, responsibility for 3.5 
requirements, IMS/VS 3.5 
network design 2.48 
network design, physical terminal 2.45 
line groups 2.44 
polled terminals 
types of polling 2.44 
switched network 2.44 
non-message driven BME 2.29 
non-update transaction processing, 
message scheduling for 2.17 
nonswitched communication lines, 
definition of 2.44 
hnonswitched network 2.50 
nonterminal-related MSDB 6.1 


Operating modes, Systemys3, System/7 2. 
Operating relationshifs, program 
description 1.2 
illustration 1.3 
options and rules for secondary 
indexes 4.113, 4.114 
options, recommended OS/VS 2.5 
Options, reguired CS/VS 2.5 
organizations, physical data base 4.14 
OS/VS data files, use of 3.5 
OS/VS options 2.5 
required 2.5 
special access method (OSAM) 2.5 
allocation of data sets 2.5 
pre-allocation restrictions 2.6 
IEFBRI4 utility 2.6 
use of 2.5 
OSAM (see overflow sequential access 
method) 
OSAM data sets, allocation of 2.5 
OSAM, DB system use of 2.5 
output call, DL/I 
example 3.14 
format 3.14 
output device, control characters 
carriage return characters 3.19 
drum address characters 3.19 
new line symbois 3.19 
purge call, [l/I 3.19 
output limits, message scheduling 2.12 
Output masks 3.24 
Output message, remote station response 
to 2.61 
output messages, Fast Path 6,15 
output to alternate destinations 
alternate FCE 3.16 
illustration 3.6 
modifiable alternate PCB 
advantages of 3. 16 
definition 3.16 
modifying, example of 3.16 
use of 3.17 
use, limitation of 3.17 
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response alternate PCB 
purpese of 3.17 
use of 3.17 
sending 3.15 
output transmission code nmodés, 
System/7 2.62 
overflow data set 4,33 
overflow sequential access method (OSAM) 
advantages to IMS/VS DB system 1.5 
functions with IMSyVS DB system 1.5 
requirements, DE system 1.5 


page-request indicator 3.22 
paging feature, 2260 and 2265 3.22 
auto delete, operation with 2.22 
function of 3.22 
page-request indicator 3.22 
using 3.22 
partners 5.5, 5.14 
password and/or terminal security 
defining 2.73 
display 2.76 
- passwords, design of 2.74 
PCB 312% 3. 13, 3. 14-3.17 
performance considerations, batch 
application program 3.10 
buffering 3.23, 1.16 
conversational frocessing 3.20 
conversion, batch to 
telecommunication 3.17 
device class control 3.18 
device independence, programming 
for 3.18 
input calls 3.14 
input/output interface 3.11 
Output calls 3.14, 3.15 
Output to alternate destinations 3.15 
paging, 2260 and 2265 3.22 
storage allocation 3.11 
tuning, using statistics for 3.10 
performance considerations, modules 
preloaded in MPPs 2.4 
physical child 
definition 4.9 
physical child last pointer 4.17, 4.18 
physical childyphysical twin pointers 
benefits of 4. 16 
rules 4.16 
use of 4.17 
physical data base 
concepts of 4.1 
calls 4.12, 4.13 
fields 4.4, 4.5 
segments 4.2, 4.3 
structure 4.6 
defining options 
HDAM or HIDAM, for 4.47, 4.48 
HISAM, for 4.47 
HSAM, for 4,47 
definition 4.1 
HDAM and HiLAM 
advantages 4.34 
organization in storage 4.14 
data set groups 4.18 
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HDAM 4,35 
HIDAM 4.37 
HISAM 4.21 
HSAM 4.19 
methods of 4, 14 
pointers 4,14 
Organization of 4.14 
rules for defining logical 
relationships in 
logical child 4.62 
logical parent 4.62 
physical parent 4.63 
physical data base hierarchy, 
defining 4.9 
physical delete rule 4.102 
logical, treated as 4.101 
violation, detection of 4.100 
physical insert rule 4.71 
example of 4.72 
physical insert rule, example of 4.72 
physical link, MSC 5.4 
physical/logical terminal 
relationships 2.50 
physical parent 
definition 4.9 
physical parent -- bidirectional virtual 
delete, example of 4,92 
physical parent pointers, data base 4.61 
physical parent, delete rules for 4.80 
physical parent, rules for defining 4.63 
physical replace rule 4.66 
example 4.67 
physical terminal network design 2.45 
physical terminals 2.42 
definition 2.42 . 
input/output assignments 2.50 
LINEGRP macro 2.44 
logical terminals, relationship 
to 2.50 
types of, supported 2.43 
physical terminals, input relationship 
to 2.50 
physical terminals, output relationship 
to 2.50 
physical twin 
definition 4.10 
illustration 4.11 
physically paired bidirectional logical 
relationship 
use of 4.56 
pointers, data base 
direct address 4.14 
illustration 4,15 
types of 4.14 
hierarchic 4&. 16 
illustration 4,17 
options 4.16 
physical child/physical twin 4.16 
backward pointers 4.17 
benefits of 4.16 
illustration 4.18 
rules 4.16 
use of 4.17 
pointing, hierarchic forward 4. 16 
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peinting, hierarchic forward and 
backward 4.16 
polled terminals 2.44 
pool, lcecgical terminal 2.52 
pool manager, MFS 2.55 
pools, control block 2.26 
postpone type station, Systen/3, 
System/7 2.62 
power warning feature S/370 1.21 
pre-allocation, OSAM data set 2.5 
multiple volume data set 2.6 
restrictions 2.6 
primary requests 5.8 
Frimary groups 5.9 
priorities, message scheduling 2.10 
process control System/7 2.€0 
processing intent specifications, 
message scheduling 2.20 
intent types 
EXCLUSIVE 2Zz.2z1 
READ ONLY 2.21 
UPDATE 2.21 
scheduling options 2.20 
processing limits, message 
scheduling 2.12 
processing regions 
defining maximum 2.7 
initialization 2.2 
types 2.1 
processing secondary index as a data base 
guidelines and restrictions 4.120 
processing sequence, secondary 
indexes 4.111 
processing, batch (see batch processing) 
program communication block (FCB) 3.6 
‘definition 3.6 
program contrcller, DB system environment 
functions 1.13 
prograp isolation 2.8 
application program abnormal 
termination 2.23 
Synchronization point, definition 
of 2.24 
call function (ROLL) 2.25 
definition 2.8 
dynamic log, maintenance of 
cperation of 2.23, 2.24 
selection for termination 2.25 
uses for 2.8 
program specification block (PSB) 1.7 
description of 1.10 
generation of 1.7 
purpose of 1.7 
segment sensitivity 
data independence, for 1.10 
levels of 1.10 
program specification block (PSB) 


2623, 2.24 


' generaticn 


illustration 1.7 

PSBGEN procedure 1.7 

results of 1.7 

use of 1.10 
program-to-program switch 5.6, 5.10 
program types, Fast Path 6.14 
programming language, choice of 3.2 


programs, testing 3.20 
protection of command functions 2.74 
PSB (see program specification block) 
/PSTOP link 5. 14 
purge call, DL/I 3.19 

illustration 3.19 

output termination, to cause 3.19 


queue data sets 
block size 
relationships 

queues 
message 2.32 
operation of 2.33, 2.34 
preformatted 2.33, 2.34 
recoverability of 2.33, 2.34 


2.33, 2.34 
2033, 2.34 


recovery capabilities, MSC 5.15 
region class 2.10 
regions, types of 2.1 
remote logical terminals 5.5 
remote station, intelligent 2.59 
remote system 5,3 
remote transactions, MSC 5.7 
reorganization, data base 4.150 
HDAM and HIDAM data kases 4.152 
HISAM data bases 4.151 
reoryanization interval 4.151 
replace (REPL) 4.13 
introduction 4.64 
rules 4,66 
coding 4.65 
illustration 4.70 
logical 4.66 
physical 4.66 
Virtual 4,66 
status code 4.66 
use of 4.13 
replace call, the 4.66 
/RSTART LINE command 5.13 
restarting the IMS/VS control region 2.28 
restructured data base 4,145 
root segment 
definition 4.7 
insertion, HISAM data base 4, 26 
insertion sequence 4.27 
root segment type pointer options, HIDAM 
data base 4,40 
routing exit routines, MSC 
link input 5.10 


5.10, 5.11 


scheduling priority for specified 
transactions 2.11 
scratch pad areas (SPAs) 
definition of 2.17 
secondary data set groups, HISAM data 
bases 
description and use 4,33 
overflow data set 4,33 
when used 4,33 
secondary indexing (see indexes, 
secondary) 
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secondary request 5.8 
security and privacy, DB/DC system 2.72 
command functions, protection against 
authorized use of 2.74 
class frofile system 2.74 
individual user profile 2.74 
Fasswords 2.74 
display bypass feature 2.76 
identity code Zz.73 
installation responsibilities 2.77 
levels of security 2.78 
limiting access to data 2.76 
log tape, using 2.77 
password security 2.73 
RACF 2.72 
recommendations for design 2.72 
resource access security 2.74 
application group 2.74 
security maintenance utility, 
(SMU), IMS/VS 2.72, 2.74, 2.75 
security violation attempts, 
recording of 2.77 
Signon verification security 2.75 
system log 2.75 
switched terminal security, 3270 2.77 
terminal security 2.73 
link security 2.73 
transaction codes, restricing entry 
of 2.73 
transaction command security 2.75 
violation control 2.77 
3270 switched terminal security 2.77 
security maintenance, MSC 5.7 
security maintenance utility, IMS/VS 2.72 
security violaticn attempts, recording 
of 2.74 
security, design considerations for 
system 2.72 
SEGM statement, use of 
PARENT= operand 4.9 
segment deletion, HISAM data base 
ISAM/CS AM ed2 
VSAM 4,32 
segment edit/compression 4.126 
considerations for use 4.128 
conversion to use 
steps for 4.127 
data compression 
definition and use 4.127 
descripticn of 4.125-4.127 
exit 4.125 
illustration 4.126 
key compression 
definition and use 4.127 
segment types, compressible 4.127 
use of 4.125 
segnent formats, data base 
data portion 4,3 
delete byte 4.3 
delete byte, illustration 4.4 
Ifo 3.8 
use of 4.3 
illustration 4,3 
prefix 4.2 
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related, how 4,3 
segment code 
use of 4,3 
types 4.3 
fixed length 4.2 
variable length 4.2 
segment oriented program 3.7 
segment search arguments (SSAs) 3.7, 3.9 
definition of 4. 14 
illustration 3.8 
definition of 3.7 
parts of 4.14 
qualified 3.7 
unqualified 
definition of 3.7 
segment search arguments, secondary 
indexes 4.120 
segment types, relating through a logical 
child 4.49 
segments, data base 4.2 
data portion 4.2 
defining 4.2 
definition 4 
fields 4.4 
formats 4.2 
delete byte 4.3 
delete byte, illustration 4.4 
illustration 4.3 
segment code 4.3 
length 4.2 
limitaticn of 4.2 
prefix 4.2 
SEGM statement 4.2 
types 4.2 
segments, data entry data base 6.4 
access 6.7 
formats 6.10-6.12 
length 6.7 
processing 6.8 
segments, variable length 
advantages of 4.122 
conversion to 4.125 
formats 4.123 
illustration 4,124 
loading 4.122 
performance, effects on 4,124 
storage requirements for, 
additional 4.124 
uses 4.122 
sequential dependent delete utility, 
DEDB 6.14 
shared index data bases, secondary 
indexes 4.119 
Sign on, switched network 
IAM command (IMS/VS) 2.51, 2.53 
names, logical terminal 2.53 
verification security 2.75 
simple HISAM data base 4,33 
Single data set group segmentation, 
HISAM 4.138 
size of root addressable area, formula 
for 4.35 
SPA 3.20, 5.11 
space allocation, IMS/VS 4,155 
Space search algorithm, HD 4.44 
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space utilization, direct access 
storage 4,134 
SSA 4,14 
STAE/ESTAE, use of 1.21 
/7START LINE command 5.12 
Status code, insert call 4.72 
status code, replace code 4.66 
storage sequence of segments, HISAM data 
base record 4,131 
structure, physical data base 4.6 
data base record 
contents 4.9 
data base structure in storage 4,7 
defining 4.6 
developing, example 4.7 
hierarchy of segment types 4.7 
creating 4.7 
hierarchy, defining 4.9 
hierarchic structure 4.10 
physical child 4.9 
physical parent 4.9 
physical relationships 4.9 
root segment 4.9 
SEGM statement, use of 4.10 
level 
order of dependence 4.9 
subpool, logical terminal 2.53 
Suppression of entries, secondary 
indexes 4.118 
switched communication lines, definition 
of 2.43 
Switched network 2.51 
design considerations 2.45 
Switched terminal security, 327C 2.77 
synchronization block, use of 2.61 
synchronization process, Fast 
Path 6.8, 6.16 
synchronizaticn transmission block 2.59 
SYSID system identification 5.6 
SYSCUT devices, use of 
program testing 3.20 
spocl option 3.20 
system console, CS/VS 
functions available 2.54 
primary purpose 2.54 
System definition, IMS/VS 2.50, 2.7 
system definition, Systen/s3, 
Systeps7 2.62 
system execution, data base 1.12 
system generation design decisions, 
CB 1.4 
system queue space, requirements for 2.8 
System related fields, secondary indexes 
defining 4.117 
types of 4.115 
/CK 4.118 
/SX 4.118 
system identification, MSC 5.6 
System/3, design considerations unigue 
to 2.70 
Systemys3, System/7 requirements 2.62 
Systemn/7, design considerations unigue 
to 2.68 


task ID field (ID) 4.42 
telecommunication application program 
design 3.11 
telecommunication) 
terminal commands, authorizing use 
of 2.73 
terminal configurations 
supported 2.42-2,44 
terminal identifier 2.60 
terminal-related MSDB 6.1 
fixed 6.1 
dynamic 6.1 
terminal response mode 
' definition 2. 16 
line performance, effects on 2.16 
options 2.16 
terminal security, design 
considerations 2.73 
terminal types, selection of 2.42-2.44 
terminal, master 2.53 
terminals, polled 2.44 
testing, application 
requirements for 3.4 
tradeoffs 4.140 
transaction attributes 5.11 
transaction command security 2.75 
transaction oriented system 3.1, 3,3 
transaction codes 2.9 
restricting entry of 2.73, 2.75 
transactions 
application programs, relation to 2.9 
attributes, defining 2.9 
transmission block System/s3, IHS/VS 
processing of 2.70, 2.71 
transmission block System/7, IMS/VS 
processing of 2.69 
transmission blocks 2.59 
transmission control 2.61 
transmission limit, System/3, Systen/7 
defining 2.63 


unauthorized processing, prevention of 
(see transacticn command 
security) 2.75 
unbuffered/buffered terminals, 
considerations 2.46 
unidirectional logical relationship 
use of 4,55 
unit-of-work, DEDB 6.6 
utilities 
data base recovery 4.149 
data base reorganization 4.150 
HDAM and HIDAM data bases 4,152 
HISAM data bases 4,151 
reorganization interval 4.151 
utility control facility 4.155 
utility, MFS 2.54 
utilizing slack space, HISAM 4.135 
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